Файл: TP_3_att.docx

Понятие автоматизированного тестирования. Автотесты. Достоинства и недостатки автоматизированного тестирования.

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

Преимущества.

•Экономия времени – программа-робот гораздо быстрее перебирает тестовые варианты, чем любой человек

•Исключение человеческого фактора – вероятность совершения ошибки при выполнении человеком рутинных операций высока

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

Недостатки.

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

•Неприменимость к некоторым объектам, оцениваемым субъективно

•Необходимость программистских навыков у тестировщика – настоящая профессиональная автоматизация тестирования невозможна без работы непосредственно с кодом тестового скрипта

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

Типы автоматизированного тестирования, их цели. Средства автоматизированного тестирования.

функциональное (в том числе модульное, или unit-тестирование),

регрессионное (проверка работоспособности старого функционала и отсутствия ранее исправленных дефектов в новых версиях)

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

Средства автоматизации.

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

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

Средства функционального тестирования.

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

Mercury WinRunner от QuickTest оно отличается тем, что приходится много вручную работать с кодом, написанным на спец. языке TSL

Segue SilkTest относительно удобное средство, предоставляющее широкие возможности для ручной работы со стандартными и нестандартными объектами на объектно-ориентированном языке 4Test

Средства нагрузочного тестирования.

Mercury LoadRunner удобный инструмент, обладающий широчайшим спектром возможностей

Segue SilkPerformer хорошее средство со своими + и -

RadView WebLoad неплохая программа для тестирования Web-приложений

Утверждения, параметры утверждений

Утверждения - гипотезы, высказываемые тестировщиком относительно результатов выполнения того или иного теста. Если гипотеза подтвердилась, то начинает выполняться следующий тест (либо тестирование завершается), иначе - ошибка. Все утверждения являются static методами класса Assert и, обычно, содержат 2 параметра: ожидаемый р-тат и действительный: Assert.AssMethod(expected, actual); Примеры:Assert.Greater( x, y );StringAssert.IsMatch( “Hello!”, MyStr );

Однако для каждого метода существуют перегружаемые варианты, которые содержат дополнительные параметры, позволяющие сформировать строку сообщения. Дополнительный параметр может быть обычной строкой, либо строкой со списком параметров, добавляемых в сообщение о результатах выполнения теста:Assert.AreEqual( int expected, int actual, string message ); Аssert.AreEqual( int expected, int actual, string message, params object[] parms ).

Директивы, категории директив

Специальные предложения, используемые для структурирования тестовых заданий и описания дополнительных спецификаций теста. Все директивы (атрибуты) содержатся в пространстве имен NUnit.Framework, которое должно быть включено в любой файл, содержащий тесты. Существует 5 категорий директив: Test Identification , Test Selection, Test Modification, Setup and Teardown, Parameterized Tests

Идентификаторы тестов позволяют выделять: класс, содержащий методы-тесты [TestFixture] ; отдельные методы этого класса [Test] ; а также давать описания тестов [Test, Property ("Severity", "Critical")]

Средства тестирования MS Visual Studio.

Приложение Microsoft Test Manager (MTM), поставляемое вместе с Visual Studio, начиная с версии 2010. Это приложение используется для работы над командными проектами и требует подключения к Team Foundation Server. Утилита тестирования MSTest, выполняемая в режиме командной строки. Исполняемый файл C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe.

Средства тестирования, интегрированные в среду Visual Studio, вызываются из пункта меню Тест.

Система Subversion, ее архитектура; достоинства и недостатки системы

Subversion (SVN) - централизованная система управления версиями. По сравнению с СVS: •обеспечивает лучшее управление изменениями структуры каталогов; •более эффективно хранит двоичные файлы; •имеет стандартную возможность возврата к состоянию проекта на определенный момент времени.Клиенты копируют файлы из хранилища (репозитория), создавая локальные рабочие копии, затем вносят изменения в рабочие копии и публикуют эти изменения в хранилище. При этом несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в SVN преимущественно используется модель «Копирование – Изменение – Слияние». Для файлов, не допускающих слияния (различные бинарные форматы файлов), можно использовать модель «Блокирование – Изменение – Разблокирование». При сохранении новых версий всех файлов используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.

Группы утверждений, классическая и закрытая модель утверждений

В nUnit поддерживаются 2 модели для утверждений – классическая и закрытая.Классическая модель предполагает непосредственное обращение к методам класса Assert. В закрытой модели используется единственный метод класса Assert – метод That. Этот метод возвращает объект, в котором реализована вся логика, необходимая для проверки утверждения: Assert.That( myString, Is.EqualTo("Hello") );

При таком вызове создается объект EqualConstraint, реализующий необходимую логику, поэтому вышеприведенный пример можно переписать в виде:Assert.That( myString, new EqualConstraint("Hello"));

Группы утверждений: утверждения равенства, утверждения сравнения, утверждения о типах, утверждения о строках

Равенства: Осуществляют проверку равенства значений двух своих аргументов. Два основных метода AreEqual и AreNotEqual реализованы для разных типов данных. При несовпадении типов осуществляется корректное приведение к необходимому типу. При сравнении вещественных значений в качестве третьего аргумента задается требуемая точность:Assert.AreEqual( float expected, float actual, float tolerance ). Допускается сравнение массивов и коллекций: два массива считаются равными, если равны их размеры и совпадают значения соответствующих элементов.

Сравнения: Осуществляют сравнение 2 величин. Основные методы:

Assert.Greater( int arg1, int arg2 ); Assert.GreaterOrEqual( int arg1, int arg2 ); Assert.Less( int arg1, int arg2 ); Assert.LessOrEqual ( int arg1, int arg2 );

Подобные методы реализованы и для других типов аргументов.

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

•Assert.IsInstanceOfType( Type expected, object actual );

•Assert.IsNotInstanceOfType( Type expected, object actual );

•Assert.IsAssignableFrom( Type expected, object actual );

•Assert.IsNotAssignableFrom( Type expected, object actual );

О строках: Основные методы:

•StringAssert.Contains( string expected, string actual );

•StringAssert.StartsWith( string expected, string actual );

•StringAssert.EndsWith( string expected, string actual );

•StringAssert.AreEqualIgnoringCase( string expected, string actual );

•StringAssert.IsMatch( string expected, string actual );

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

Assert.IsTrue( bool condition ), Assert.IsFalse( bool condition); Assert.IsNull( object anObject ); Assert.IsNotNull( object anObject );

Assert.IsEmpty( string aString ); Assert.IsNotEmpty( string aString );

Понятие версии программного продукта и системы контроля версий

Проблема контроля версий является одной из фундаментальных проблем программной инженерии в силу невозможности практической реализации линейной стратегии разработки программных средств и коллективного характера процесса разработки. При индивидуальной работе над проектом разработчик вынужден хранить 2 и более версий системы, чтобы иметь возможность вернуться на предыдущие стадии разработки. При коллективной разработке ситуация усложняется, поскольку возникают проблемы семантической совместимости фрагментов программного кода, созданных отдельными разработчиками, и оповещения об изменениях, вносимых в ранее написанный код каждым из разработчиков. Одним из аспектов нового подхода к организации разработки стало использование систем управления версиями – Version Control Systems (VCS). Система управления версиями - комплекс ПО, назначением которого является централизованное хранение и обработка всех или большей части файлов, из которых состоит проект некоего программного продукта.

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

Понятие «версия» в разных системах трактуется 2 способами.

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

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений (даже 1 файла) приводит к увеличению этого номера. Номера версии отдельного файла здесь, не существует, но говоря о «версии файла» в таких системах, имеют в виду ту версию репозитория, в которой файл был последний раз изменён.

Две модели версионирования, их сравнение.

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

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

При создании обновленного файла могут возникнуть две ситуации:

•нормальная: изменения, внесенные различными разработчиками, не перекрываются; их объединение происходит в автоматическом режиме; •конфликтная – некоторые из внесенных изменений перекрываются; объединение таких изменений производится «вручную» после взаимных консультаций разработчиков.

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

Система конкурирующих версий CVS, ее достоинства и недостатки

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

Достоинства: •обеспечивает возможность коллективной работы над проектом; •позволяет управлять не 1 файлом, а целыми проектами; •обладает большим кол-вом удобных графических интерфейсов; •предустановлена в большинстве ОС семейства Linux.

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

Хранилище, его структура, правки. Команды SVN для работы с хранилищем

Хранилище представляет собой последовательность фиксированных состояний размещенной в ней файловой системы. Хранилище создается с помощью входящей в состав поставки Subversion утилиты SvnAdmin путем выполнения команды:svnadmin create <путь к репозиторию>.Сразу после создания хранилище не содержит ничего, кроме пустого корневого каталога. Первоначальное заполнение хранилища осуществляется командой svn import <дерево> <URL хранилища> -m “Initial import”

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

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

Схема Метод доступа

file:/// прямой доступ к хранилищу (на локальном диске)

http:// доступ через протокол WebDAV (если Subversion-сервер работает через Apache)

https:// то же, что и http://, но с SSL-шифрованием

svn:// доступ через собственный протокол к серверу svnserve

svn+ssh:// то же, что и svn://, но через SSH-соединение

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

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

Список файлов проекта из репозитория можно просмотреть с помощью команды: svn list <URL каталога хранилища> -v. Флаг –v указывает на необходимость вывода полной информации о правке.

Утилита модульного тестирования NUnit. Средства описания тестов.

Для модульного тестирования применяются специальные утилиты, позволяющие сразу запустить все тесты и увидеть результат. Одной из наиболее популярных из них является свободно распространяемая утилита Nunit. Первоначально она была портирована с языка Java (библиотека JUnit) и написана на J#. Затем весь код был переписан на C# с использованием таких новшеств .NET, как атрибуты. Существуют расширения оригинального пакета NUnit, большая часть из них также с открытым исходным кодом. NUnit.Forms дополняет NUnit средствами тестирования элементов пользовательского интерфейса. Для написания тестов можно использовать скриптовое расширение любого из .Net языков программирования. Основными элементами описания тестов являются утверждения (assertions) и директивы (directives).

Сценарий объединения правок. Конфликты и способы их разрешения

Смешивание правок. Следует иметь в виду, что рабочие копии не всегда соответствуют какой-то одной правке в хранилище; они могут содержать файлы из разных правок. Фиксация локальных изменений. После внесения изменений в файл рабочей копии разработчик может зафиксировать внесенные изменения, выполнив команду:svn commit <параметры> <путь к файлу>. В результате в хранилище создается новая правка. Обновление рабочей копии. Для актуализации рабочей копии используется команда: svn update <путь к рабочей копии> При этом обновляются только те файлы, в которые вносились изменения между обновлениями. Служебный каталог. В служебном каталоге .svn для каждого файла рабочего каталога записывается следующая информация:

•на какой правке основан рабочий файл (рабочая правка файла);

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

•не изменялся и не устарел: Файл не изменялся в рабочем каталоге, а в хранилище также не фиксировались изменения этого файла со времени создания его рабочей правки; Команды svn commit и svn update никаких операций делать не будут.

•изменялся локально и не устарел: Файл был изменен в рабочей копии, но в хранилище не фиксировались изменения этого файла в рабочей копии; Есть локальные изменения, которые не были зафиксированы в хранилище, поэтому svn commit выполнит фиксацию этих изменений, а svn update не сделает ничего.

•не изменялся и устарел: В рабочем каталоге файл не изменялся, но был изменен в хранилище; Необходимо выполнить обновление файла для того, чтобы он соответствовал текущей опубликованной правке; Команда svn commit не сделает ничего, а svn update обновит рабочую копию файла в соответствии с последними изменениями.

•изменялся локально и устарел: Файл был изменен как в рабочем каталоге, так и в хранилище; Команда svn commit потерпит неудачу, выдав ошибку «out-of-date»; Файл необходимо сначала обновить. Команда svn update попытается объединить локальные изменения с опубликованными; Если Subversion не сможет выполнить объединение самостоятельно, она предложит пользователю разрешить конфликт вручную.

Понятия рабочей копии и служебного каталога. Команды SVN для работы с рабочими копиями

Рабочая копия – моментальный «снимок» состояния хранилища или некоторой его части, сохраненный на компьютере клиента. Она представляет собой дерево каталогов, содержащее набор различных файлов. Файлы рабочей копии могут произвольным образом редактироваться разработчиком, оставаясь недоступными другим разработчикам. После внесения изменений в файлы рабочей копии и проверки их корректности разработчик может записать свою версию в хранилище, т.е. опубликовать. Если другие участники проекта производили редактирование тех же файлов и уже опубликовали свои изменения, Subversion предоставляет возможность для объединения этих изменений с рабочей копией данного разработчика.

Рабочая копия содержит дополнительные файлы, созданные и обслуживаемые Subversion, которые используются при выполнении слияний. В частности, каждый каталог рабочей копии содержит подкаталог с именем .svn, который называется служебным каталогом рабочей копии. Файлы в служебном каталоге помогают определить, какие файлы рабочей копии содержат неопубликованные изменения и какие файлы устарели по отношению к файлам других участников.

Документирование процесса разработки. Типы документов управления

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

Типы документов управления:

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

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

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

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

•Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками

Документирование программного продукта. Документация сопровождения, ее назначение и состав

Документация по сопровождению ПС описывает ПС с точки зрения ее разработки. Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ. Документация по сопровождению ПС можно разбить на 2 группы: документация, определяющая строение программ и структур данных ПС и технологию их разработки; документация, помогающая вносить изменения в ПС. Документация 1й группы содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы: внешнее описание ПС; описание архитектуры ПС, включая внешнюю спецификацию каждой ее программы; для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля; для каждого модуля - его спецификация и описание его строения ;тексты модулей на выбранном ЯП; документы установления достоверности ПС, описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС. Документы установления достоверности ПС включают документацию по тестированию, но могут включать и результаты других видов проверки ПС. Документация 2й группы содержит руководство по сопровождению ПС, которое описывает известные проблемы, связанные с ПС, какие части системы являются аппаратно- и программно-зависимыми, возможности дальнейшего развития ПС.

Документирование программного продукта. Пользовательская документация, ее назначение и состав

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

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

Генератор документации Sandcastle, его назначение и принцип работы

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и/или по исполняемым модулям, полученным на выходе компилятора. Sandcastle имеет 2 основных компонента:

MrefBuilder – генерирует XML-файл, используя механизм отражения; BuildAssembler генерирует файлы, выполняет преобразования и т. д.

MrefBuilder получает информацию из сборки и выдает ее в выходной файл – Reflection.xml; для каждого объекта исходной сборки – пространства имен, класса, свойства, метода и т. п. этот файл содержит свой тэг <api> с подробным описанием. В готовом справочнике каждому тэгу <api> будет соответствовать свой HTML-файл описания. След. шаг: дополнение файла Reflection.xml серией дополнительных тэгов <api>. Для этого используются XSLT-преобразования, которые выполняются утилитой XslTransform. В результате формируется ряд преобразованных .xml файлов, которые подаются на вход компонента BuildAssembler. Справочник и файлы справки, полученные на выходе BuildAssembler и XslTransform, преобразуются в HTML Help при помощи HTML Help Compiler.

Руководство проектом и особенности проектной деятельности

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

Проектная команда, группы и роли в проектной команде

Роли и ответственности участников типового проекта разработки ПО можно условно разделить на пять групп: •Анализ. Извлечение, документирование и сопровождение требований к продукту. •Управление. Определение и управление производственными процессами. •Производство. Проектирование и разработка ПО. •Тестирование. Тестирование ПО. •Обеспечение. Производство дополнительных продуктов и услуг.

Группа анализа: Бизнес-аналитик. Построение модели предметной области. Бизнес-архитектор. Определяет общее видение продукта.

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

Группа тестирования: Проектировщик тестов. Разработка тестовых сценариев. Разработчик автоматизированных тестов. Тестировщик. Тестирование продукта. Анализ и документирование результатов.

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

Критерии оценивания проектов, шкалы ценности проекта

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

Шкала оценки финансовой ценности: Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованы. Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания. Средняя. Проект позволяет улучшить эффективность производства в компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес. Низкая. Проект снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.

Шкала оценки стратегической ценности: Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет. Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года. Средняя. Поддерживается доверие рынка к компании. Повышает мнение клиентов о качестве предоставляемых услуг или способствует выполнению обязательств перед несколькими клиентами. Конкуренты уже имеют или способны повторить новые возможности в пределах года. Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.

Шкала оценки уровня рисков: Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы. Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе. Выше среднего. Цели проекта недостаточно четки. Задачи системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены. Системы создаются на новой технологической платформе. Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе. Технологии имеют неподтвержденную стабильность.

Риски, их ранжирование, управление рисками

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

Базовое расписание проекта, точки контроля, распараллеливание работ

Базовое расписание - утвержденный план-график с указанными временными фазами проекта, контрольными точками и элементами иерархической структуры работ. Базовое расписание м.б. наиболее наглядно представлено диаграммой Ганта, содержащей плановые операции или элементы иерархической структуры работ, даты начала и завершения длительность операций. Распараллеливание задач требует согласования процессов их выполнения во времени. Для каждой из них должно быть запланировано приемлемое время решения Tproc, а также раннее Tmin и позднее Tmax время начала решения. Необходимо выделить задачи, образующие основу проекта, и определяющие временные рамки его выполнения

Способы контроля хода выполнения проекта: меры и метрики. Виды метрик.

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

Размерно-ориентированные метрики основаны на LOC-оценках (кол-ве строк в текстах программ, lines of code): производительность (длина(тыс. LOC)/затраты(чел.-мес.)), качество (ошибки(ед.)/ длина(тыс. LOC)), удельная стоимость (стоимость(тыс.руб)/ длина (LOC)), документированность (страниц документа/ длина(тыс. LOC)).

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

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