Как можно разделить различные подходы к управлению проектами.

ГОСТы

ГОСТ 19 "Единая система программной документации" ^[2] и ГОСТ 34 "Стандарты на разработку автоматизированных систем" ^[3] ориентированы на последовательный подход в разработке программного обеспечения. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ. Строгое следование этим ГОСТам приводит к каскадной модели. На основе этих стандартов разрабатываются программные системы по госзаказам в России.

SW-CMM

Данная модель была разработана в середине 80-ых годов ХХ века Институтом программной инженерии, входящим в состав Университета Карнеги-Мелона с целью создать эталонную модель организации разработки программного обеспечения. Основана на проверке соответствия организации определенным требованиям и определении уровня зрелости процесса разработки программного обеспечения.

RUP

Унифицированный процесс был разработан компанией Rational Software в качестве дополнения к языку UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности.

MSF

Microsoft Solutions Framework построена на основе итеративной разработки. Особенностью MSF является большое внимание к созданию эффективной и небюрократизированной команды.

PSP /TSP

Personal Software Process определеяет требования к компетенциям разработчика для того, чтобы они смогли получить необходимые навыки для Team Software Process. Team Software Process в комбинации с Personal Software Process делает ставку на самоуправляемые команды численностью 3-20 человек. Команды должны:

• Установить собственные цели
• Составить свой процесс и планы
• Отслеживать работу
• Поддерживать мотивацию и максимальную производительность

Agile

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

 

 

14. Что такое требования и как с ними работать.

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

Проверка требований

Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

Нефункциональные требования, которые являются неподдающимися проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента; Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B (англ.).

Анализ требований

Требования склонны к проблемам двусмысленности, неполноты, и несогласованности. Их устранение на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки. Анализ требований направлен на решение данных проблем.

Существует технический компромисс между слишком неопределёнными требованиями и требованиями столь детализированными что они:

1. требуют много времени для разработки, иногда даже рискуют устареть к концу разработки

2. ограничивают возможные способы реализации

3. являются слишком дорогостоящими

Документирование требований

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

В зарубежной и российской практике встречаются следующие типы документов требований:

• Концепция программы (Vision)
• Спецификация программного обеспечения (англ. Software Requirements Specification, SRS)

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

За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

 

15. Роли и обязанности участников проекта. Менеджер проекта

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

Подбор кадров и управление ими –

Формулирование и исполнение плана проекта

Руководство командой

Обеспечение связи между

Обеспечение готовности продукта

Программисты Ведущий разработчик

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

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

· согласование архитектурных вопр-в с коллегами,ответственными за разработку других ф-ций;

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

Рядовые программисты

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

Тестировщики

• планирование испытаний;
• автоматизация испытаний;
• оценка и выбор инструментальных средств.

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