Состав работ 2 этапа

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

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

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

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

· требования к программным и аппаратным компонентам системы, к базе данных, физические характеристики компонентов системы.

Следует отметить, что при проведении анализа всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации – метод MoSCoW, предложенный в 1994. Эта аббревиатура расшифровывается так:

Must have - необходимые функции;

Should have - желательные функции;

Could have - возможные функции;

Won't have - отсутствующие функции.

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

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

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

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

Состав работ 2 этапа: