Девять лучших навыков, рекомендованных SPMN

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

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

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

В рамках проекта рекомендуется постоянно вести и анализировать списки 10 важнейших рисков; списки неустраненных рисков в наиболее критических точках проекта; отчеты по устраненным, неустраненным и новым рискам; учитывать возможную стоимость последствий рисков в зависимости от имеющегося резерва. SPMN советует также использовать анонимные каналы для получения информации от персонала о неизвестных «подводных камнях» в проекте, чтобы в коллективе не создавалась атмосфера замалчивания ошибочных действий (типичная рекомендация для американской корпоративной культуры). Одновременно надо «декриминализировать» сам риск. У сотрудников не должно быть никаких иллюзий о допустимости рисков, при этом необходимо понять, что каждый выявленный риск — это предупрежденный риск.

Навык 2 — соглашения об интерфейсах: пользовательских, внутренних (межмодульных) и внешних (для стыковки с другими компонентами и приложениями).

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

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

Правильность интерфейса проверяет и утверждает только реальный пользователь каждого рабочего места из организации-заказчика. Для встраиваемой системы готовятся отдельные требования к ее внешнему интерфейсу.

Навык 3 — формальные проверки проекта. Нередко устранение ошибок начинается, только когда проект переходит к этапу тестирования. Такие этапы были придуманы 30 лет назад для создания небольших по сегодняшним меркам систем, и хотя в тестировании нет ничего плохого, выделять его в отдельный этап методически неверно. Стоимость этапа тестирования может достигать 40-60% стоимости всего проекта. Эти ненужные усилия можно сократить на порядок, однако немногие руководители знают, как это сделать.

Существует немало стандартных подходов раннего выявления ошибок, позволяющих обнаруживать 80% ошибок в момент их внесения, или многократные просмотры кода (выявляется 60% ошибок). Чтобы оперативно обнаружить 90—100% ошибок, надо использовать несколько подходов. Ведущие компании одновременно применяют 10 и более методик формальных проверок (анализ структуры проекта, проверки кода, редактирование документации, множественное тестирование и т. п.).

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

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

С помощью метрик (числовых характеристик) планируются все задачи проекта. Ход их выполнения надо регулярно отслеживать, как минимум, — по ключевым показателям (стоимость работы и производительность труда). Надо дополнительно контролировать время, затрачиваемое на устранение дефектов, и следить за важнейшими показателями, чтобы по их отклонениям (в любую сторону — например, слишком резвый старт) выявлять потенциальные «подводные камни». Метрики основываются на эмпирических данных, например, на основе результатов анализа схожих по размерам проектов.

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

В проекте надо выделить задачи объемом не более 5% по продолжительности и усилиям, которые могут быть выполнены отдельной группой сотрудников как минимум на 95%. Каждая подобная задача должна быть ориентирована на выполнение однотипной работы. Результат выполнения задачи оценивается группой приемки, при этом работа не может быть принята с оговорками: она должна быть выполнена полностью и без ошибок (двоичная система оценки качества «готово/не готово»).

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

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

Устранять ошибки необходимо по мере их возникновения. При этом учет ошибок удобнее всего вести в нормализованном виде (в расчете на единицу объема, например, на тысячу строк кода). Согласно принципу «снежного кома», с ростом объема проекта норма ошибок в нем увеличивается. Также надо контролировать среднее и максимальное время устранения ошибки и время от внесения до устранения ошибки в течение каждого этапа проекта и на протяжении первого года эксплуатации системы.

Навык 8 — управление конфигурацией. Неконтролируемые изменения в проекте могут быстро ввергнуть его в хаос. Поэтому на практике надо руководствоваться двумя простыми правилами:

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

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

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

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

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

 

1.5.

ПРИМЕР ПРОЦЕССА

«УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ»

 

Одна из первых работ при проектировании ПО — сбор и упорядочение требований к нему. Требование [10] - это условие, которому должна удовлетворять система, или свойство, которым она должна обладать, чтобы удовлетворить потребность пользователя в решении некоторой задачи и удовлетворить требования контракта, стандарта или спецификации.

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

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

· требования к производительности накладывают ограничения на функциональные требования, задавая необходимую эффективность использования ресурсов, пропускную способность и время реакции;

· требования к реализации предписывают использовать определенные стандарты, языки программирования, операционную среду и др.;

· требования к надежности определяют допустимую частоту и воздействие сбоев, а также возможности восстановления;

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

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

К требованиям не относятся способы управления проектом, планы, методы верификации, управления конфигурацией, тестовые процедуры и т.д.

Работа с требованиями порождает целый ряд проблем:

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

· требования разнообразны по типам и детальности, могут достигать огромного количества, которое трудно контролировать;

· требования разнообразны по значимости (обязательность, риск, важность, стабильность);

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

Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, отчетов существующей системы и массы других материалов. Потом их начинают упорядочивать и «очищать» от противоречий. Затем на их основе вырабатываются требования к компонентам системы - базам данных, программным и техническим средствам. При этом аналитику, проводящему обследование, приходится иметь дело с большим количеством неструктурированных, часто противоречивых требований и пожеланий, разбросанных по всевозможным соглашениям о намерениях, приложениям к договорам, протоколам рабочих совещаний, черновым материалам обследований. Без организованных усилий по регистрации и контролю за выполнением этих требований велик риск их «потерять». Кроме того, известно, что ошибки в требованиях — самые дорогостоящие и самые распространенные. Переделка ПО обычно занимает 40—50% бюджета проекта, при этом ошибки в требованиях отнимают наибольшую часть стоимости переделки ПО (>70%) и 30-40% общей стоимости бюджета проекта.

Наиболее распространенные методы проектирования ПО сосредоточены на моделировании требований с помощью различного рода диаграмм. Но в данном случае мы имеем в виду управление требованиями. Эти два понятия — моделирование и управление - не являются противоречивыми или несовместимыми.

В реальных проектах пользовательские требования зачастую должным образом не документируются; в свое оправдание разработчики говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе. Это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования необходимо выполнить, а какие можно отложить на более позднее время? Структурные и объектно-ориентированные методы не дают ответа на этот вопрос, поскольку они предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.

Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности, поскольку сами требования и их приоритеты изменяются в течение проекта. Большинство крупных проектов включает сотни требований, а многие — даже тысячи (например, проект самолета Боинг-777, который называли мешком программ с крыльями, включал, по некоторым данным, около 300 000 требований). Кроме того, некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.

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

Управление требованиями (requirements management) представляет собой:

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

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

Модель СММ характеризует деятельность по управлению требованиями следующим образом. Управление требованиями осуществляется для того, чтобы:

· достичь соглашения с заказчиком и пользователями о том, что система должна делать;

· улучшить понимание требований к системе со стороны разработчиков;

· определить границы системы;

· определить базис для планирования.

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

Например, в технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

1) требования записаны в согласованном формате;

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

3) требования структурированы в соответствии со своими типами (функциональными и нефункциональными);

4) требования отслеживаются в соответствии с их типом;

5) требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

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

Чтобы добиться осуществления целей управления требованиями и соответствия модели СММ в области управления требованиями, необходимо выделить определенные ресурсы. Нужно обучить участников разработки деятельности по управлению требованиями. Обучение должно предусматривать изложение методов и стандартов, а также способствовать формированию понимания командой разработчиков особенностей предметной области и существующих в ней проблем. Помимо обучения, организация процесса управления требованиями предусматривает:

· организацию соответствующей инфраструктуры (ответственные исполнители, инструментальные средства, средства взаимодействия (интранет/интернет, электронная почта));

· определение источников возникновения и механизмов выявления требований;

· определение процедуры обсуждения требований и правил принятия решений по ним;

· определение механизмов регистрации и обработки изменений требований и принятия решений по ним.

В процессе работы с требованиями выделяются следующие этапы:

· определение типов требований и групп участников проекта, работающих с ними;

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

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

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

· приоритет (высокий, средний, низкий);

· статус (предложено, одобрено, утверждено, реализовано, верифицировано);

· стоимость (высокая, средняя, низкая или числовое значение);

· сложность реализации (высокая, средняя, низкая);

· стабильность (высокая, средняя, низкая);

· исполнитель.

Еще одним важным аспектом управления требованиями является трассировка. Трассировка требований — это установка связей требований с другими требованиями или проектными решениями. Цель трассировки требований:

· убедиться, что все требования к системе выполнены в процессе реализации;

· убедиться, что ПО делает только то, что предполагалось;

· облегчить внесение изменений в ПО (управление изменениями).

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

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

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

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

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

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

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

· существенное влияние на архитектуру системы;

· рискованные, сложные для реализации или срочные функции;

· применение новой, неапробированной технологии;

· значимость в экономических процессах.

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

 

1.6.

ПРИМЕР ПРОЦЕССА

«УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ ПО»

 

Управление конфигурацией ПО[11] (см. подразд. 1.2.2) является одним из наиболее важных вспомогательных процессов жизненного цикла ПО. Цель управления конфигурацией — обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонентов в каждый момент времени, а также обо всех предполагаемых и выполненных в процессе сопровождения изменениях.

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

Изменения разделяются на следующие группы:

· срочные изменения, которые должны не только быть внесены в очередную версию ПО, но и сообщены пользователям для оперативной модификации ПО до внедрения официальной версии;

· изменения, которые целесообразно внести в очередную версию с учетом затрат на их реализацию ПО;

· изменения, которые требуют дополнительного анализа целесообразности и эффективности их реализации, в последующих версиях и могут не внедряться в очередную версию ПО;

· изменения, которые не оправдывают затрат на их внесение или практически не влияют на качество и эффективность ПО, и поэтому не подлежат реализации.

Изменение конфигурации ПО должно планироваться и предусматривать в плане действия с четкими разделами:

· почему и с какой целью производится модификация ПО;

· кто выполняет и санкционирует проведение изменений;

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

· когда по срокам и в координации с какими другими процедурами следует реализовать определенную модификацию ПО;

· как и с использованием каких средств и ресурсов должны быть выполнены запланированные изменения ПО.

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

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

· объектов - модулей и компонентов ПО, подвергающихся модификации;

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

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

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

Наиболее развитые современные средства управления конфигурацией и изменениями ПО обладают следующими возможностями:

· хранение в БД управления конфигурацией полных хронологий версий каждого объекта, созданного или измененного в процессе разработки системы (к ним относятся исходный программный код, библиотеки, исполняемые программы, модели, документация, тесты, web-страницы и каталоги);

· поддержка географически удаленных групп разработчиков;

· контроль изменений, вносимых во все объекты системы;

· сборка версий ПО из компонентов проекта.

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

Средства контроля изменений обычно используются в комплексе со средствами управления требованиями. Поступающее требование или замечание проходит четыре этапа обработки:

· регистрация — внесение замечания в базу данных;

· распределение — назначение ответственного исполнителя и сроков исполнения;

· исполнение — устранение замечания, которое, в свою очередь может вызвать дополнительные замечания или требования на дополнительные работы;

· приемка — приемка работ и снятие их с контроля или направление на доработку.

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

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

! Следует запомнить

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

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

3. Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наиболее распространенными моделями являются каскадная и итерационная.

4. Зрелость процессов ЖЦПО — это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.

Основные понятия

Нормативно-методическое обеспечение, жизненный цикл программного обеспечения, процессы жизненного цикла, модель ЖЦ ПО, стадия процесса создания ПО, каскадная модель, итерационная модель, зрелость процессов.

 

? Вопросы для самоконтроля

1. Что такое жизненный цикл программного обеспечения?

2. Чем регламентируется ЖЦ ПО?

3. Какие группы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?

4. Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степени и почему?

5. Какие стадии входят в процесс создания ПО?

6. Каково соотношение между стадиями и процессами ЖЦ ПО?

7. Каковы принципиальные особенности каскадной модели?

8. В чем заключаются преимущества и недостатки каскадной модели?

9. Каковы принципиальные особенности итерационной модели?

10. В чем состоят преимущества и недостатки итерационной модели?

11. Каким образом можно добиться повышения уровня зрелости процессов создания ПО?

12. Какую роль в повышении уровня зрелости играют процессы управления требованиями и управления конфигурацией ПО?

 

 

ГЛАВА 2

МЕТОДИЧЕСКИЕ АСПЕКТЫ

ПРОЕКТИРОВАНИЯ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

Прочитав эту главу, вы узнаете:

· В чем заключаются общие принципы проектирования систем и что такое визуальное моделирование.

· Что представляет собой структурный подход к анализу и проектированию ПО.

· В чем заключается метод функционального моделирования SADТ.

· Как строятся диаграммы потоков данных и диаграммы «сущность — связь».

· Что представляет собой объектно-ориентированный подход к анализу и проектированию ПО.

· В чем заключаются основные особенности языка моделирования UML.

· Как строятся модели и диаграммы, входящие в состав UML.

· Что представляют собой образцы.

 

2.1.