Терещенко Андрей Владимирович
Коммерческий директор, ОАО "Белебеевский завод Автонормаль"
Тема доклада: «Металл для производства автокомпонентов: особенности и проблемы»
Российские производители автокомпонентовсегодня не стоят на месте и предпринимают активные действия не только по удержанию существующих рынков сбыта, но и по освоению новых за счет улучшению потребительских качеств и снижения стоимости существующих продуктов. Он отметил, что БелЗАН также ведет освоение новых видов продукции, выходит на новых потребителей, включая зарубежных сборщиков на территории России, для чего налаживает взаимодействие с поставщиками подката для производства автокрепежа на предприятии, а также высказал пожелания по повышению качества сырья, перечислив основные проблемы, с которыми приходится сталкиваться заводу при использовании отечественного подката.
Терещенко Андрей Владимирович
Коммерческий директор, ОАО "Белебеевский завод Автонормаль"
Тема доклада: «Металл для производства автокомпонентов: особенности и проблемы»
Российские производители автокомпонентовсегодня не стоят на месте и предпринимают активные действия не только по удержанию существующих рынков сбыта, но и по освоению новых за счет улучшению потребительских качеств и снижения стоимости существующих продуктов. Он отметил, что БелЗАН также ведет освоение новых видов продукции, выходит на новых потребителей, включая зарубежных сборщиков на территории России, для чего налаживает взаимодействие с поставщиками подката для производства автокрепежа на предприятии, а также высказал пожелания по повышению качества сырья, перечислив основные проблемы, с которыми приходится сталкиваться заводу при использовании отечественного подката.
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
Внедрение СМК и управление качеством с M-Files QMSFTS Russia
M-Files QMS - одна из немногих систем, разработанных при участии специалистов-практиков СМК, поэтому в ней учтены все потребности организаций, сертифицированных в соответствии с международными стандартами и развивающими систему менеджмента качества.
В данном решении доступен функционал по управлению различными типами документации, утверждению документов с помощью электронной подписи, обучению сотрудников, управлению отклонениями, контролю корректирующих и предупреждающих мероприятий, постановке задач сотрудникам.
Подробнее о решении M-Files QMS:
http://fts-eu.com/ru/c/M-Files-QMS-Upravlenie-kachestvom/
О компании:
Компания FTS оказывает услуги по автоматизации бизнес-процессов и внедряет ИТ-системы для бизнеса с 1994 года. Компания FTS официально представляет решения Deltek Maconomy, M-Files и Microsoft в России и СНГ.
Если вам понравилась система или у вас появились вопросы, свяжитесь с нами по почте: info.ru@fts-eu.com или по телефону: + 7 495 950 54 69, + 7 499 978 77 34.
Dnepr IT PM Club #11
Speaker - Vladimir Semenov [Project Manager at Apriorit Inc.]
https://www.linkedin.com/in/vladimir-semenov-pmp-121a08a9/
Тема: "Управление содержанием, ошибки и best practices"
Основные тезисы:
- Что такое содержание проекта
- Инструменты, артефакты и процессы
- Место управления содержанием в жизненном цикле разработки
- Как сформировать оптимальный набор практик для разных проектов и заказчиков
О спикере:
PM в компании Apriorit, 5 лет опыта работы в IT Project Management. Основное направление работы - высоконагруженные клинет-серверные приложения
Управляемое внедрение. Основы управления распределенными программными проекта...Cергей Мартынов
Доклад Александра Белова об управлении распределенными проектами вызвал огромный интерес участников на проходившей в Санкт-Перербурге первой независимой профессиональной конференции INFOSTART EVENT 2012.
Module 4 On going service consumption vs deliverables expectationsNatalia Perestyuk
ИТ-аутсорсинг: сервис с ответственностью за процесс работы команды (team leasing) или за поставленные наработки (deliverables) с успешным приёмочным тестированием
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
Внедрение СМК и управление качеством с M-Files QMSFTS Russia
M-Files QMS - одна из немногих систем, разработанных при участии специалистов-практиков СМК, поэтому в ней учтены все потребности организаций, сертифицированных в соответствии с международными стандартами и развивающими систему менеджмента качества.
В данном решении доступен функционал по управлению различными типами документации, утверждению документов с помощью электронной подписи, обучению сотрудников, управлению отклонениями, контролю корректирующих и предупреждающих мероприятий, постановке задач сотрудникам.
Подробнее о решении M-Files QMS:
http://fts-eu.com/ru/c/M-Files-QMS-Upravlenie-kachestvom/
О компании:
Компания FTS оказывает услуги по автоматизации бизнес-процессов и внедряет ИТ-системы для бизнеса с 1994 года. Компания FTS официально представляет решения Deltek Maconomy, M-Files и Microsoft в России и СНГ.
Если вам понравилась система или у вас появились вопросы, свяжитесь с нами по почте: info.ru@fts-eu.com или по телефону: + 7 495 950 54 69, + 7 499 978 77 34.
Dnepr IT PM Club #11
Speaker - Vladimir Semenov [Project Manager at Apriorit Inc.]
https://www.linkedin.com/in/vladimir-semenov-pmp-121a08a9/
Тема: "Управление содержанием, ошибки и best practices"
Основные тезисы:
- Что такое содержание проекта
- Инструменты, артефакты и процессы
- Место управления содержанием в жизненном цикле разработки
- Как сформировать оптимальный набор практик для разных проектов и заказчиков
О спикере:
PM в компании Apriorit, 5 лет опыта работы в IT Project Management. Основное направление работы - высоконагруженные клинет-серверные приложения
Управляемое внедрение. Основы управления распределенными программными проекта...Cергей Мартынов
Доклад Александра Белова об управлении распределенными проектами вызвал огромный интерес участников на проходившей в Санкт-Перербурге первой независимой профессиональной конференции INFOSTART EVENT 2012.
Module 4 On going service consumption vs deliverables expectationsNatalia Perestyuk
ИТ-аутсорсинг: сервис с ответственностью за процесс работы команды (team leasing) или за поставленные наработки (deliverables) с успешным приёмочным тестированием
These are the cultural values that RedMartians live every day in order to become the most customer-centric company in the world and the best place to work.
Становление программы внутренних аудитов.Elena Petrova
Выступление Петровой Елены на конференции SQA Days (2012г). Организация внутренних аудитов Системы Менеджмента Качества (на базе опыта компании Team International)
6. Стоимость ошибок в требованиях 31% проектов прекращены 53% проектов превысили бюджет вдвое 13% - недостаток исходной информации от клиента 12% - неполные требования и документы требований 12% - изменение требований и документов требований Исследования Standish Group Причины краха проектов
8. Системный аналитик Системный аналитик Спонсоры проекта Представители пользователей Другие заинтерес. лица Заказчик Руководитель проекта Разработка Тестирование Проектная команда
12. Требования Заказ- чик Потреб- ности Реали- зация Процесс управления требованиями Команда Применение СМК к управлению требованиями
13. Уровни зрелости CMMI Модель СММ I является структурой, представляющей последовательность усовершенствований, которые рекомендуются для организаций-разработчиков, желающих повысить продуктивность своего производственного процесса
В настоящее время разработка информационных систем является жизненно важной составляющей мировой экономики. Постоянно развивающийся в условиях конкуренции бизнес требует от компаний снижения стоимости продукции и услуг, а также выпуска их на рынок в конкурентоспособные сроки. Для удовлетворения подобных потребностей компании вынуждены автоматизировать свои бизнес-процессы с помощью информационных систем. Целью данной работы является сбор, обобщение и дополнение существующих на сегодняшний день методов оценки качества требований к программному обеспечению. На основе полученных данных необходимо построить и описать формализованный процесс управления качеством требований, а также привести рекомендации по сбору, анализу и документированию требований. Процесс управления качеством необходимо построить на основе модели зрелости CMMI с применением концепции типовых решений для описания требований. Необходимость создания процесса управления качеством требований вызвана потребностью увеличения скорости разработки программного обеспечения в условиях быстро меняющегося и развивающегося бизнеса. Формализованный процесс управления качеством требований позволит сократить сроки разработки программного обеспечения за счет сокращения сроков проверки качества требований, что приведет также и к сокращению стоимости проекта. Заказчика информационной системы, несомненно, привлечет исполнитель, который может разработать качественную систему в наименьшие сроки и с минимальным бюджетом. Раздел «Требования к программному обеспечению» содержит определение понятия «требование», классификацию требований и их место в процессе разработки программного обеспечения. В разделе также приводятся количественные данные, показывающие денежные затраты на переделывание проекта в случае ошибочно определенных требований. Раздел «Управление требованиями» описывает процесс управления требованиями, его основные шаги, артефакты и роли. Здесь также описаны стадии сбора, анализа, документирования и проверки требований. Раздел «Качество требований» определяет, что такое «качество» и как оно проецируется на требования к разработке программного обеспечения. Раздел также знакомит с критериями качества требований, дает краткое описание модели CMMI и основных концептуальных представлений, лежащих в основе уровней зрелости. Раздел «Управление качеством требований» описывает формализованный процесс управления качеством требований, построенный на основе модели зрелости CMMI , уровни зрелости, основные элементы и характеристики каждого уровня. Даны рекомендации по улучшению и оценке качества требований к программному обеспечению и советы плавного перехода от одного уровня зрелости к следующему.
На сегодняшний день существует множество определений термина требование к программному обеспечению ( software requirement ). Наиболее подходящим, на мой взгляд, является определение, приведенное в [2]: Требования - условия или возможности, необходимые пользователю для решения проблем или достижения целей. Требования - условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам.
Для удобства работы с требованиями и управления требованиями их классифицируют по типам. Классификация требований по определенным типам позволяет разделять требования по уровням абстракции, природе, назначению и другим признакам. «Бизнес требования» (business requirements) описывают высокоуровневые цели организации или заказчиков системы. «Ключевая возможность» ( key feature) - это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют «бизнес требованиям». В области коммерческого программного обеспечения «ключевая возможность» представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке - элемент маркированного списка в описании продукта. «Пользовательские требования» (user requirements) описывают цели и задачи, которые пользователи смогут решать при помощи системы. «Характеристики качества» ( quality of service ) описывают цели и атрибуты качества разрабатываемой системы. К требованиям данного типа относятся технические ограничения и бизнес-правила. Технические ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, используемых языков программирования, технологий и платформ. Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. «Функциональные требования» (functional requirements) определяют функциональность программного обеспечения, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках «пользовательских» и «бизнес требований»
Цель разработки программного обеспечения состоит в том, чтобы, уложившись в отведенное время и бюджет, разработать качественное программное обеспечение. В большинстве случаев, успех проекта зависит от хорошо организованного процесса разработки и управления требованиями. Ошибки в требованиях являются наиболее встречающимся типом ошибок при разработке систем, а их идентификация и устранение являются наиболее дорогостоящими. Из представленного рисунка видим, что при обнаружении ошибок на стадии формирования требований получаем экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии поддержки. Эксперты в области разработки программного обеспечения утверждают, что переделывание ошибок в требованиях может обойтись в 25-40% общего бюджета проекта и 70-85% бюджета переделок. Исследования Standish Group покали, что 31% проектов будет прекращен до завершения. Затраты на 52,7 % проектов составляют 189% от первоначальной оценки. К наиболее часто встречающимся факторам, создающим «проблемы» в программных проектах, относятся следующие: Недостаток исходной информации от клиента: 13% проектов Неполные требования и документы требований: 12% проектов Изменение требований и документов требований: 12% проектов. Напротив, наиболее важными факторами успеха проектов были выделены следующие: Подключение к разработке пользователей: 16% успешных проектов Поддержка со стороны исполнительного руководства: 14 % Ясная постановка требований: 12%
Цель разработки программного обеспечения состоит в том, чтобы, уложившись в отведенное время и бюджет, разработать качественное программное обеспечение. В большинстве случаев, успех проекта зависит от хорошо организованного процесса разработки и управления требованиями. Ошибки в требованиях являются наиболее встречающимся типом ошибок при разработке систем, а их идентификация и устранение являются наиболее дорогостоящими. Из представленного рисунка видим, что при обнаружении ошибок на стадии формирования требований получаем экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии поддержки. Эксперты в области разработки программного обеспечения утверждают, что переделывание ошибок в требованиях может обойтись в 25-40% общего бюджета проекта и 70-85% бюджета переделок. Исследования Standish Group покали, что 31% проектов будет прекращен до завершения. Затраты на 52,7 % проектов составляют 189% от первоначальной оценки. К наиболее часто встречающимся факторам, создающим «проблемы» в программных проектах, относятся следующие: Недостаток исходной информации от клиента: 13% проектов Неполные требования и документы требований: 12% проектов Изменение требований и документов требований: 12% проектов. Напротив, наиболее важными факторами успеха проектов были выделены следующие: Подключение к разработке пользователей: 16% успешных проектов Поддержка со стороны исполнительного руководства: 14 % Ясная постановка требований: 12%
Управление требованиями – это процесс систематического выявления, организации и документирования требований к программному обеспечению, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Каждый представленный выше шаг в процессе управления может повторяться множество раз, причем, переходы от шага к шагу могут быть прямыми и обратными. Обратная связь позволяет уточнять, дорабатывать и корректировать требования. На этапе планирования системный аналитик создает план управления требованиями и шаблоны необходимой документации. Планирование – первый шаг при работе с требованиями, он начинается на этапе предпроектного обследования Выявление требований является самой сложной задачей в процессе управления требованиями. От того насколько полно собраны требования, зависит реализация проекта и последующее удовлетворение заказчика. Первой задачей при выявлении требований является определение пользователей информационной системы, которые будут работать с системой, и если не учесть их потребностей, конечный продукт может потерпеть неудачу. Стадия выявление требований является расходящимся процессом, которая нацелена на сбор большого количества информации. После выявления требований, аналитик имеет большое количество различной информации, полученной на интервью, при обследовании, из анкет и других источников. Полученную информацию необходимо уточнить, структурировать, исключить дублирование, сформулировать в виде требований и определить их приоритеты. Эти задачи решает стадия анализа требований. Целью анализа требований является получение понятных и непротиворечивых требований, на основе которых можно проектировать и реализовывать программное приложение. На данной стадии создаются модели требований, определяются недостающая информация, требования уточняются и для каждого требования задаются значения его атрибутов. Параллельно с процессом анализа требования описываются в проектной документации. Как говорилось ранее, требования могут документироваться при помощи текстового описания или в виде графических диаграмм. К основным документам, описывающим требования, относятся глоссарий, документ-концепция и спецификация требований. После того, как требования собраны и задокументированы, необходимо проверить качество требований и разработанных документов. В проверке качества требований участвует вся команда разработки программного обеспечения, а также эксперты предметной или другие представители заказчика. Требования к разрабатываемой системе могут изменяться не одни раз в процессе ее разработки. Причиной изменения требований могут служить результаты анализа требований, их уточнение, запросы пользователей на изменение системы, новые требования от заказчика и многое другое. Для того чтобы отслеживать все изменения и принимать решения о том, изменять требование или нет, необходимо использовать процесс управления изменениями требований.
Процесс управления требованиями одна из сложнейших задач в разработке программного обеспечения. Для работы с требованиями требуется высококвалифицированный специалист, обладающий знаниями предметной области заказчика, информационных технологий и коммуникабельностью. Системный аналитик является членом команды разработки программного обеспечения и отвечает за весь процесс управления требованиями. Системный аналитик служит связующим звеном между заказчиком и командой разработки, является «переводчиком» языка заказчика на язык разработчиков. Бизнес-аналитик Бизнес-архитектор Аналитик требований Спецификатор требований Системный архитектор Технический писатель Коммуникатор
Джозеф Джуран – гуру в области управления качеством, говорил, что качество есть степень удовлетворения потребителя и для реализации качества производитель должен изучить требования потребителя и произвести свою продукцию так, чтобы она удовлетворяла этим требованиям. Данное высказывание определяет жесткую взаимосвязь качества производимого продукта и требований, предъявляемых к разработке данного продукта. Следовательно, от того насколько полно и качественно собраны требования к программному обеспечению зависит его качество. Конечно, «хорошие» требования не гарантируют получения качественного программного продукта, но способствуют этому в первую очередь. Слова Джурана подтверждает определение термина качества, приведенное в стандарте ISO 9001 [17]: Качество – совокупность свойств и характеристик продукции, способных удовлетворить установленные и предполагаемые потребности заказчика.
Стандарт ISO 9001 устанавливает требования к системе менеджмента качества (СМК), как к процессному подходу . Из рисунка видно, что требования потребителя (заказчика, пользователя) являются входом для процесса управления качеством. Процесс управления качеством сфокусирован на трех основных принципах: требования потребителя, управление процессом, непрерывное совершенствование. Стандарт ISO 9001:2000 ничего не говорит о том, как правильно получить требования, как добиться приемлемого качества самих требований. Для решения данной проблемы, необходимо применить описанные выше принципы к процессу управления требованиями. В результате мы получим процесс, на выходе которого будут качественные требования, т.е. в роли продукции будут выступать требования к программному обеспечению, а в роли потребителей проектная команда: архитекторы, программисты, инженеры по тестированию и другие. Данные принципы являются основополагающими для применения процессного подхода к управлению качеством требований программного обеспечения. Первый и второй принципы достигаются за счет внедрения процесса управления требованиями, третий принцип – за счет поэтапного внедрения данного процесса. При делении процесса управления требованиями на этапы, необходимо учесть то, что каждый последующий этап, должен расширять задачи и деятельность предшествующего этапа, другими словами процесс должен быть инкрементным. Для решения данной задачи необходимо построить процесс на основе уровней зрелости CMMI.
Стандарт ISO 9001 устанавливает требования к системе менеджмента качества (СМК), как к процессному подходу . Из рисунка видно, что требования потребителя (заказчика, пользователя) являются входом для процесса управления качеством. Процесс управления качеством сфокусирован на трех основных принципах: требования потребителя, управление процессом, непрерывное совершенствование. Стандарт ISO 9001:2000 ничего не говорит о том, как правильно получить требования, как добиться приемлемого качества самих требований. Для решения данной проблемы, необходимо применить описанные выше принципы к процессу управления требованиями. В результате мы получим процесс, на выходе которого будут качественные требования, т.е. в роли продукции будут выступать требования к программному обеспечению, а в роли потребителей проектная команда: архитекторы, программисты, инженеры по тестированию и другие. Данные принципы являются основополагающими для применения процессного подхода к управлению качеством требований программного обеспечения. Первый и второй принципы достигаются за счет внедрения процесса управления требованиями, третий принцип – за счет поэтапного внедрения данного процесса. При делении процесса управления требованиями на этапы, необходимо учесть то, что каждый последующий этап, должен расширять задачи и деятельность предшествующего этапа, другими словами процесс должен быть инкрементным. Для решения данной задачи необходимо построить процесс на основе уровней зрелости CMMI.
Стандарт ISO 9001 устанавливает требования к системе менеджмента качества (СМК), как к процессному подходу . Из рисунка видно, что требования потребителя (заказчика, пользователя) являются входом для процесса управления качеством. Процесс управления качеством сфокусирован на трех основных принципах: требования потребителя, управление процессом, непрерывное совершенствование. Стандарт ISO 9001:2000 ничего не говорит о том, как правильно получить требования, как добиться приемлемого качества самих требований. Для решения данной проблемы, необходимо применить описанные выше принципы к процессу управления требованиями. В результате мы получим процесс, на выходе которого будут качественные требования, т.е. в роли продукции будут выступать требования к программному обеспечению, а в роли потребителей проектная команда: архитекторы, программисты, инженеры по тестированию и другие. Данные принципы являются основополагающими для применения процессного подхода к управлению качеством требований программного обеспечения. Первый и второй принципы достигаются за счет внедрения процесса управления требованиями, третий принцип – за счет поэтапного внедрения данного процесса. При делении процесса управления требованиями на этапы, необходимо учесть то, что каждый последующий этап, должен расширять задачи и деятельность предшествующего этапа, другими словами процесс должен быть инкрементным. Для решения данной задачи необходимо построить процесс на основе уровней зрелости CMMI.
Уровень зрелости представляет собой четко определенную стадию эволюции организации на пути к зрелому производственному процессу и соответствует уровню продуктивности производственного процесса. Каждое описание уровней зрелости разбивается на составные части. Разбиение каждого уровня зрелости, кроме первого, варьируется от кратких обзоров уровня до его рабочего определения в ключевых практиках.. Уровень зрелости состоит из нескольких групп ключевых процессов. Каждая группа ключевых процессов разбита на разделы. В разделах приводятся ключевые практики, при совместном выполнении которых достигаются цели группы ключевых процессов.
Уровень зрелости представляет собой четко определенную стадию эволюции организации на пути к зрелому производственному процессу и соответствует уровню продуктивности производственного процесса. Каждое описание уровней зрелости разбивается на составные части. Разбиение каждого уровня зрелости, кроме первого, варьируется от кратких обзоров уровня до его рабочего определения в ключевых практиках.. Уровень зрелости состоит из нескольких групп ключевых процессов. Каждая группа ключевых процессов разбита на разделы. В разделах приводятся ключевые практики, при совместном выполнении которых достигаются цели группы ключевых процессов.
В соответствии со стандартом ISO 9001:2000 качество продукта должно быть измеряемым. Очевидно, что одной из мер качества является получение в результате завершения проекта хорошего продукта, но как говорилось ранее, помимо требований существует множество других факторов, влияющих на результат. Исходя из этого, необходимо оценивать качество документов с требованиями и моделей требований. Правильное - Критерий того, насколько требование соответствует предметной области и потребностям заказчика Однозначное - Критерий, характеризующий однозначность толкования требования и однозначность понимания его всеми заинтересованными лицами. Полное - Критерий, характеризующий требования с точки зрения полноты предоставленной информации для дальнейшего его проектирования и реализации. Непротиворечивые - Критерий, характеризующий то, что два или несколько требований не противоречат друг другу, т.е. при реализации одного требования не возникало конфликтов или невозможности реализации другого требования. Ранжированное - Критерий, характеризующий важность требований Проверяемое - Критерий, характеризующий возможность проверки требования с использованием механизмов тестирования (функционального, нагрузочного и др.) Прослеживаемое - Критерий, характеризующий отношения между требованиями. Понимаемое - Критерий, характеризующий возможность заинтересованному лицу понять данное требование Модифицируемое - Критерий, характеризующий возможность сохранения структуры и стиля описания набора требований при изменении требований. Модель уровней зрелости CMMI предназначена для непрерывного совершенствования процессов организации-разработчика программного обеспечения и предназначена для оценки и достижения организацией соответствующего уровня зрелости, характеризующего процессы и качество выпускаемой продукции. Используя подход, предлагаемый CMMI , целью данной работы является разработка модель зрелости процесса управления требованиями, другими словами, вместо организации с ее производственными процессами будем рассматривать конкретный процесс. В результате необходимо получить декомпозицию процесса управления требованиями на уровни зрелости, для каждого уровня зрелости описать его ключевые шаги, решаемые задачи и артефакты, а также привести примеры практик, использующихся для улучшения качества требований.
Процесс управления качества требованиями к программному обеспечению разработан в соответствии с уровнями зрелости аналогично уровням зрелости CMMI. В основе лежат шесть уровней зрелости процесса управления качеством требований. Каждый последующий уровень полностью включает в себя предшествующий, что способствует непрерывному совершенствованию процесса. Процесс управления качеством на основе уровней зрелости позволит командам – разработчикам совершенствовать свой процесс работы с требованиями поэтапно, улучшая его на каждом последующем этапе. В соответствии с концепцией постоянного улучшения качества, после перехода на следующий этап команда должна закрепить на практике все соответствующие процессу действия.
Нулевой уровень зрелости по умолчанию может быть присвоен любой команде, которая разрабатывает программное обеспечение. Игнорирование стадии выявления требований приводит к тому, что программный продукт не удовлетворяет потребностям заказчика потому, что в нем отсутствует необходимый функционал или, наоборот, реализованы функции, которые заказчику не нужны. Важность подобных проблем зависит от заказчика и критичности программного обеспечения, но в большинстве случаем, особенно при разработке крупномасштабных систем данные проблемы могут привести к провалу всего проекта.
Цель уровня зрелости «Документирование требований» заключается в получении документов, описывающих требования. Наличие документов с требования является отправной точкой для процесса управления требованиями, поскольку являются базисом для дальнейшей разработки программного обеспечения. На основе документов с требованиями разрабатываются сценарии тестирования, архитектура программного обеспечения, руководства пользователя и другая проектная документация. Интервью является одним из основных способов получения требований от заказчика. В большинстве случаев, данные процессы уже задокументированы в различных регламентах, инструкциях, правилах и другой документации. В таком случае аналитику не требуется проводить интервью с заказчиком и требуется лишь изучить существующую документации и получить из нее необходимую информацию для дальнейшего формирования из нее требований к программному обеспечении. На первом уровне зрелости подразумевается описание требований в отдельном документе, на данном этапе не выдвигается требований к оформлению документа и его структуре. Проектная команда должна лишь описывать требования для того, чтобы на их основе осуществлять разработку программного продукта. Экспертная оценка позволяет проектной команде получить требования, не противоречащие предметной области. Экспертная оценка приводит к получению требований, соответствующих критерию качества – правильность . Согласование спецификации требований с заказчиком, позволяет установить уровень ответственности команды разработчиков по отношению к заказчику. Согласование также позволяет устанавливать границы проекта, договариваться о бюджете и сроках реализации.
Целью второго уровня зрелости является получение набора требований, понятных заказчику и членам проектной команды. Требования должны понятно , непротиворечиво и однозначно описывать желаемое поведение разрабатываемой системы. Для того, чтобы получить требования с такими критериями качества, необходимо разработать шаблоны документов, собрать требования в единой базе данных и вести историю их изменений. Анкетирование применятся в тех случаях, когда аналитику сложно встретиться с заказчиком по причине удаленности их друг от друга, маркетологами исследуется рынок, и система разрабатывается для продажи, сложно определить конечных пользователей системы и выделить среди них того, с кем можно проводить интервью. Мозговой штурм является превосходным способом поиска новых идей для разрабатываемой системы и ее предметной области. Цель мозгового штурма сфокусироваться на проблеме и предложить определенное количество радикальных идей по решению данной проблемы. Первым шагом к анализу требований является поиск противоречивых и не полных требований. В результате проверки требований или в момент их документирования, могут возникнуть конфликты между требованиями, что приведет к необходимости уточнения требований. В таком случае необходимо снова вернуться к выявлению требований, чтобы заполнить пробелы в информации и исправить возникшие противоречия. Для того, что документ был читаемым, понятным и простым в использовании при его разработке нужно применять шаблоны документов, с необходимыми стилями форматирования. Часто на практике документация разрабатывается в соответствии с установленными заказчиком стандартами. В таких случаях, документ должен полностью соответствовать всем предъявляемым к нему требования по оформлению. Коллективная проверка требований является разновидностью экспертной оценки. В данном случае в проверке качества требований участвуют не только аналитик и эксперт предметной области, а также другие члены проектной команды ( проверяемость ). При большом количестве рецензентов спецификации требований рекомендуется использовать отдельный документ, в котором записываются замечания проверяющих и комментарии аналитика, разрабатывающего спецификацию Требования могут храниться не только в текстовом документе. Альтернативой является размещение их в базе данных. Наличие базы данных с требованиями позволяет уникально идентифицировать каждое требования, определять права членов команды для доступа к требованиям, создавать любые запросы в базу данных, осуществляя сложные выборки требований по различным критериям. При работе с большим количеством требований, особенно на этапах их уточнения и переделки, необходимо вести историю версий требований и спецификаций. Версионность позволяет просматривать историю изменения требований, узнавать, кто и зачем изменил требования, а в случае ошибок возвращаться к более ранним версиям.
Цель третьего уровня зрелости заключается в необходимости планирования процесса управления качеством требований, разделения требований на типы по объединяющим признакам. План управления требований формализует процесс управления, так как четко определяет типы требований, их атрибуты, набор необходимой документации и задачи, связанные с управлением требованиями. Для того чтобы классифицировать требования необходимо разбить их по типам. С помощью атрибутов осуществляется управление требованиями, отслеживание состояний требований, задание дополнительной информации, расширяющей текстовое содержание требования. Подход на основе вариантов использования ( Use Case Driven Approach ) позволяет не только описывать пользовательские требования, он лежит в основе объектно-ориентированного подхода к разработке программного обеспечения. Это метод анализа и проектирования сложных систем, представляющий собой способ описания поведения системы с точки зрения того, как различные пользователи взаимодействуют с ней для достижения своих целей. Такой ориентированный на пользователя подход позволяет исследовать различные варианты поведения системы при привлечении пользователя на ранних этапах разработки. Параллельно с вариантами использования рекомендуется применять прототипы разрабатываемой системы. Структурировать требования можно с помощью разбиения документов на разделы или на основе моделей анализа требований. Структура моделей анализа подразумевает собой декомпозицию моделей по пакетам и диаграмма. Правильно структурированные требования позволяют достичь многих критериев качества, в том числе модифицируемости . Использование шаблонов является хорошим способом стандартизации языка, применяемого для разработки требований. При этом для того, чтобы иметь возможность писать стандартным способом требования различных типов, необходимо просто собрать определенный набор шаблонов Применение моделей при анализе и документировании требований позволяет решить проблемы понимания требований и дальнейшего моделирования и проектирования программной системы. При использовании моделей для анализа требований возможен плавный и последовательный переход к моделям проектирования Контрольные листы ( checklists ) используются как технология контроля качества требований. Они представляет собой набор вопросов, которые аналитик или другой член команды, задает себе при проверке требований. Рекомендация ( guideline ) предоставляет дополнительную информацию о том, как работать с определенным документом, моделью и задачей. К рекомендациям часто относятся учебные материалы, пояснения и другая информация, помогающая аналитику решить его задачу или разъяснить непонятные моменты в работе.
Целью установки отношений между требованиями (трассировки) является получение возможности отслеживания изменений требований, их влияния друг на друга, возможность идентификации избыточных и неучтенных требований В результате интервью могут появиться нерешенные вопросы. Для решения подобных вопросов и обсуждение требований проводятся специальные семинары. Как правило, на семинары приглашаются представители заказчика и члены проектной команды. В отличие от семинара, фокус группа собирается для решения определенной проблемы, как правило, по взаимодействию различных подсистем разрабатываемой системы. При разработке большинства систем (особенно крупномасштабных) разрабатывается огромное количество требований, которые могут создавать иерархию требований. Иерархия может начинаться на уровне бизнес - моделирования и постановки целей, проходить через потребности пользователей и заканчиваться детальными требованиями к разрабатываемой системе и ее компонентам. Способность отследить отношения между требованиями называется прослеживаемостью и определяется отношениями трассировки между требованиями. Прослеживаемость обеспечивает способность понимания того, как изменения одного требованию могут повлиять на другие требования (анализ влияния), а также может помочь в определении того, полны ли требования (анализ полноты учета) Часто на практике аналитики используют кратность при определении отношений между требованиями. Кратность позволяет задать правила, которые определяют количество участвующих в отношениях требований. Анализ влияния показывает, как изменение одного требования может воздействовать на другие Анализ сферы деятельности позволяет оценивать то, есть ли у каждого требования высокого уровня связанное с ним требование более низкого уровня. Это помогает определить, есть ли в требованиях непокрытые участки. Также как и шаблон, типовое решение является подходом к описанию определенного типа требований
Пятый уровень зрелости нацелен на использование требований не только для согласования с заказчиком, но и для дальнейшей разработки программного обеспечения. Для создания программного обеспечения, соответствующего требованиям заказчика (особенно при возможности их изменения), необходимо процесс разработки программного обеспечения построить таким образом, чтобы проектная команда использовала требования как основную входную информацию. Так как требования являются основой процесса управления проектом, у руководителя проекта должен быть прямой доступ к состоянию проекта в отношении требований. Состояние определяет наличие новых, реализованных, проверенных требований. Аналитики и руководитель проекта также могут оценивать и предотвращать риски, связанные с требованиями. Требования к программному обеспечению лежат в основе планирования, потому что по их количеству, сложности реализации, приоритетам и рискам, планируются сроки проекта и его бюджет. Сложнейшей задачей является определение трудозатрат необходимых на описание, проектирование и реализацию требований, т.е. количественная оценка каждого требования. При интеграции с другими приложения, такими как CASE средства, модели требований могут разрабатываться в их среде. Следовательно, можно разрабатывать отчеты на основе данных моделей и генерировать документацию с требованиями. Современные инструментальные средства проектирования и разработки программного обеспечения, позволяют получить почти все необходимую информацию, касающуюся моделей требований, моделей анализа и проектирования. Пятый уровень зрелости предполагает внедрение системы управления изменениями. Системы подобного рода позволяют отслеживать все изменения, произведенные в требования, и гарантировать, что ни одно изменение не произведено в требованиях без просмотра и одобрения В данной работе собраны практики и рекомендации по улучшению качества требований к программному обеспечению. На основе собранных и обобщенных данных построен и описан формализованный процесс управления качеством программных требований с использованием уровней зрелости CMMI . В работе предложены рекомендации по внедрению процесса в реальные проекты по разработке программного обеспечения, даны советы по переходу от одного уровня зрелости к другому. В дополнение к описанному процессу рассмотрены примеры описания варианта использования, шаблона технического задания и плана управления требованиями, разработанные в соответствии с государственными стандартами Российской Федерации. Уникальность данного процесса заключается в возможности его поэтапного внедрения с постоянным наращиванием задач и действий, выполнение которых способствует инкрементному улучшению качества требований к программному обеспечению.
![Содержание ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)