Методология SCRUM: сущность и области применения.

Scrum — методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

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

Главные действующие роли в Scrum:

ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самогоScrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster);

Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон;

Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Ежедневно проводятся мини-митинги, в конце каждого месяца – большое собрание.

На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (список бизнес-требований и технических требований), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

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

Стандарты ИСО в области системной и программной инженерии

Состав нормативно-технических документов

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

Обозначение	Наименование
ГОСТ Р ИСО/МЭК 12207-99	Информационная технология. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК ТО 15271-2002	Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 9126-93	Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению
ГОСТ Р ИСО/МЭК 15910-2002	Информационная технология. Процесс создания документации пользователя программного средства
ГОСТ Р ИСО/МЭК ТО 9294-93	Информационная технология. Руководство по управлению документированием программного обеспечения
ГОСТ Р ИСО/МЭК 15288-2005	Информационная технология. Системная инженерия. Процессы жизненного цикла систем
ISO/IEC 15289	Системная и программная инженерия. Содержание информационных продуктов (документации) процессов жизненного цикла систем и программных средств
ISO/IEC 26514	Системная и программная инженерия. Требования для проектировщиков и разработчиков документации пользователя
ISO/IEC 26513	Системная и программная инженерия. Требования по экспертизе и тестированию документации пользователя
ГОСТ Р 51904-2002	Программное обеспечение встроенных систем. Общие требования к разработке и документированию
ISO/IEC 18019: 2004	Программная инженерия. Руководство по разработке и подготовке пользовательской документации на прикладные программные средства
ISO 6592: 2000	Обработка информации. Руководство по документации для вычислительных систем
ГОСТ Р ИСО 9127-94	Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.

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

Стандарт ГОСТ 34.601-90

В основе канонического проектирования лежит каскадная модель жизненного цикла ИС.

Процесс каскадного проектирования в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34.601-90 «Автоматизированные системы

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к АС

1. Обследование объекта и обоснование необходимости создания АС

2. Формирование требований пользователя к АС

3. Оформление отчета о выполнении работ и заявки на разработку АС

2. Разработка концепции АС

1. Изучение объекта

2. Проведение необходимых научно-исследовательских работ

3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

4. Оформление отчета о проделанной работе

3. Техническое задание

1. Разработка и утверждение технического задания на создание АС

4. Эскизный проект

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

2. Разработка документации на АС и ее части

5. Технический проект

1. Разработка проектных решений по системе и ее частям

2. Разработка документации на АС и ее части

3. Разработка и оформление документации на поставку комплектующих изделий

4. Разработка заданий на проектирование в смежных частях проекта

6. Рабочая документация

1. Разработка рабочей документации на АС и ее части

2. Разработка и адаптация программ

7. Ввод в действие

1. Подготовка объекта автоматизации

2. Подготовка персонала

3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

4. Строительно-монтажные работы

5. Пусконаладочные работы

6. Проведение предварительных испытаний

7. Проведение опытной эксплуатации

8. Проведение приемочных испытаний

8. Сопровождение АС.

1. Выполнение работ в соответствии с гарантийными обязательствами

2. Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Процессы жизненного цикла информационной̆ системы. ГОСТ 12 207

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

1) Процесс заказа (подраздел 5.1). Определяет работы заказчика, то есть организации, которая приобретает систему, программный продукт или программную услугу.

2) Процесс поставки (подраздел 5.2). Определяет работы поставщика, то есть организации, которая поставляет систему, программный продукт или программную услугу заказчику.

3) Процесс разработки (подраздел 5.3). Определяет работы разработчика, то есть организации, которая проектирует и разрабатывает программный продукт.

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

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

 

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

1) Процесс документирования (подраздел 6.1). Определяет работы по описанию информации, выдаваемой в процессе жизненного цикла.

2) Процесс управления конфигурацией (подраздел 6.2). Определяет работы по управлению конфигурацией.

3) Процесс обеспечения качества (подраздел 6.3). Определяет работы по объективному обеспечению того, чтобы программные продукты и процессы соответствовали требованиям, установленным для них, и реализовывались в рамках утвержденных планов. Совместные анализы, аудиторские проверки, верификация и аттестация могут использоваться в качестве методов обеспечения качества.

4) Процесс верификации (подраздел 6.4). Определяет работы (заказчика, поставщика или независимой стороны) по верификации программных продуктов по мере реализации программного проекта.

5) Процесс аттестации (подраздел 6.5). Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

6) Процесс совместного анализа (подраздел 6.6). Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.

7) Процесс аудита (подраздел 6.7). Определяет работы по определению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой).

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

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

1) Процесс управления (подраздел 7.1). Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.

2) Процесс создания инфраструктуры (подраздел 7.2). Определяет основные работы по созданию основной структуры процесса жизненного цикла.

3) Процесс усовершенствования (подраздел 7.3). Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

4) Процесс обучения (подраздел 7.4). Определяет работы по соответствующему обучению персонала.

 

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

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

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

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

Предпосылки стандартизации

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

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

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

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

 

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

Вернемся к примеру с токарем. Чтобы его труд был успешным, ему необходимы:

• то, с помощью чего производить — то есть станок и режущий инструмент;
• то, из чего производить — материалы;
• описание того, как производить — чертежи и технологические карты.

Почему же в этом смысле, например, работник бухгалтерии, как типичный представитель «непроизводственной» сферы, оказывается в менее выгодном положении? Рабочее место и компьютерную программу для ведения учета ему предоставили, а где же «описание того, как производить»? Где инструкции по ведению учета для того участка, который курирует бухгалтер? Почему имеет место такая профессиональная дискриминация?
Конечно, квалифицированный бухгалтер должен быть способен работать без вспомогательных средств. Но даже бухгалтер со стажем, приходя на новое место работы, даже на знакомый ему участок учета, все равно какое-то время затратит на адаптацию, на погружение в особенности хозяйственной и учетной практики данного предприятия.
Наличие же корпоративных стандартов позволяет сократить срок «ввода в эксплуатацию» нового работника до минимума, обеспечивает более быстрое получение отдачи от работника. И даже после того, как специалист выйдет на номинальный режим работы, внутренние нормативные документы облегчат его работу. И совсем не нужно всю методологию ведения повторяющихся учетных операций держать в голове, всякий раз с большим или меньшим трудом извлекая ее оттуда. Человек имеет свойство уставать, забывать и, вследствие этого, ошибаться. Вероятность ошибок многократно снижается, когда исполнитель по каждому поводу обращается не в кладовые своей памяти, а к грамотной, достаточно простой и наглядной инструкции.
Экипаж воздушного судна имеет наиподробнейшие инструкции, регламентирующие его деятельность от этапа подготовки к взлету до этапа посадки. Что воспринимается совершенно естественно — любая ошибка в пилотировании ведет к летному происшествию или катастрофе. В этом смысле, конечно, ошибка бухгалтера не создает непосредственной угрозы здоровью и жизни людей, но на безопасности бизнеса компании может сказаться самым непосредственным образом.
Внутреннее положение по ведению учета — это инструмент для соблюдения правил техники безопасности для бухгалтера. А если сказать более обобщенно, наличие внутренних нормативных документов создает базу для обеспечения безопасности бизнеса компании в целом.

 

7.Управление конфигурацией: содержание процесса управления конфигурацией, организация информационной поддержки процесса управления конфигурацией

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

⇐ Предыдущая123456789Следующая ⇒

Поделиться: