Этапы разработки программного обеспечения глазами компании
Этап разработки – это период между основными пунктами в процессе, в котором формируются задачи, презентуются готовые рабочие продукты и принимаются решения о переходе на следующий этап.
1. Стратегический этап
Цель стратегического этапа состоит в том, чтобы описать проект с точки зрения клиента, только в этом случае разработка программного обеспечения позволит получить на выходе программный продукт, полностью отвечающий требованиям заказчика. Все цели могут показаться иногда очевидными. Однако попытка определить их обычно позволяет избегать возможного недоразумения между клиентом и изготовителем. Кроме того, даже если цели ясны для всех людей, вовлеченных в стратегический этап, они не будут очевидны для людей, работающих на последующих стадиях и людей, не имеющих прямого контакта с клиентом. Целью проекта должно быть подробное описание требований на случай, если возникают какие-либо сомнения в последующих этапах.
Следующее задание, которое выполняется на стратегическом этапе, состоит в том, чтобы описать возможности проекта. Обычно развитая система будет поддерживать некоторые аспекты деятельности клиента. Соответствующее описание возможностей необходимо для хорошей стоимостной оценки проекта. Однако клиент не знает возможностей проекта на данном этапе. Может быть непонятно, какие функции будут выполнены в ПО и какие функции будут осуществлены пользователями, другими системами и аппаратными средствами.
Определение возможностей проекта приводит к контекстному описанию, то есть к описанию внешних систем, с которыми взаимодействовала бы система. Во многих случаях система используется одним или несколькими пользователями. Этих пользователей рассматривают как внешнюю систему.
Определения целей, возможностей и контекста проекта недостаточно для стоимостной оценки производства и сложных систем. Точная оценка возможна только если все этапы, такие как формулировка требований, анализ и проектирование, были выполнены. Практически финансовые ресурсы доступны в стратегическом этапе, ограничены, поэтому рекомендуется производить только общую оценку. Важно учитывать все возможности описанной системы.
Стратегический этап называют этапом проектирования. Он выполняется прежде, чем приняты окончательные решения. В случае компании, производящей ПО для клиента, это этап ведения переговоров о продукте с клиентом. В случае, когда компания разрабатывает ПО для рынка, это этап обсуждения и планирования продукта. Это чрезвычайно ответственная работа, требующая креативного мышления и большого опыта работы в данной сфере, именно поэтому вакансии для разработчиков, специализирующихся на проектировании, чрезвычайно востребованы - к примеру, такой специалист без проблем сможет устроиться в компанию CreatikSoft.
Стратегический этап также называют технико-экономическим исследованием. На этом этапе выполняются следующие действия:
• обсуждение проекта с представителями клиента;
• определение цели проекта с точки зрения клиента;
• определение возможностей и контекста проекта;
• приблизительная формулировка требований, анализ и проект системы;
• формулирование альтернативных решений;
• анализ;
• представление результатов представителям клиента и осуществление исправлений;
• предварительное планирование и выбор структуры команды;
• стандартные определения.
В случае разработки системы ПО для клиента мы должны различать человека-заказчика и людей, которые будут использовать и применять систему. В общем, наш проект должен соответствовать требованиям заказчиков, так как продукт будет оцениваться ими. Очень часто они не являются пользователями системы. Именно этими критериями руководствуются специалисты компании CreatikSoft при разработке программного обеспечения.
На этом этапе существует несколько стратегических решений, которые должны быть приняты:
• выбор модели проекта;
• выбор методов, которые будут использоваться для анализа и проектирования;
• выбор программной среды;
• выбор CASE-инструментов;
• решение об использовании наборов инструментов;
• решение о возможном сотрудничестве.
Как правило, есть несколько вероятных решений по системе и эти варианты решений подчинены определенным ограничениям. Ограничения могут касаться:
• максимальная допустимая стоимость;
• доступные профессионалы и персонал;
• доступные инструменты;
• ограничение во времени.
На стратегическом этапе выполняется предварительное планирование (определяются подзадачи и оценивается время, необходимое для их выполнения). Поэтому детали проекта еще не определены и график работы очень общий.
На стратегическом этапе должны быть установлены стандарты. Они включают:
• использование инструментов и понятий;
• методы документирования.
Оценка решения может быть основана на таких критериях как стоимость, затраты времени на проект, надежность, повторное использование компонентов системы, мобильности и способ выполнения.
К ключевым факторам успеха на стратегическом этапе относятся:
• эффективность работы (особенно для компаний, работающих на конкретного клиента на рынке конкурирующих компаний, любые задержки могут привести к низким шансам на новые заказы);
• Независимо от разрабатываемой системы, компания не может потратить значительные средства на стратегическом этапе ( таким образом, этап должен быть организован небольшой группой людей и в короткие сроки);
• непонимание ключевых моментов клиентом (этот фактор делает успех проекта невозможным);
• осмысление всей системы (большинство неудач, вызванные в результате уделения очень большого внимания некоторым фрагментам системы, то есть отсутствует понимание частей, которые могут быть самыми трудными в разработке).
К основным результатам стратегического этапа относятся:
• составление отчета, охватывающего;
• определение цели;
• описание возможностей;
• описание внешних систем;
• описание общих требований;
• общая модель системы;
• предложенное решение по системе;
• стоимостная оценка;
• предварительное планирование;
• отчет об относительной оценке решения, содержащий информацию обо всех возможных решениях и обосновании принятых решений;
• представление необходимых ресурсов – штата, аппаратных средств, программного обеспечения и т.д.;
• стандартные определения;
• планирование анализа.
2. Этап определения требований
Цель этого этапа состоит в том, чтобы подробно описать требования клиента. На этом этапе мы описываем все требования, ведущие к достижению цели. Мы должны иметь в виду, что клиент может не понять их техническую точку зрения. Таким образом формулировка требований – процесс коммуникации с клиентом, в котором клиент и разработчик устанавливают ряд соответствующих требований.
У компании, создающей ПО для клиента, аналитики имеют прямой контакт с представителями клиента. Постоянное обсуждение с представителями клиента, в большинстве случаев являющееся пользователями системы, приводят к формулированию всех деталей требований. Рекомендуется, чтобы один человек со стороны клиента был ответственен за коммуникацию представителей клиента с аналитиками.
Затруднения на этом этапе возникают по следующим причинам:
• клиент не знает, как цели могут быть достигнуты ( существует много способов достижения целей);
• большие системы используются многими пользователями. Возможны противоречия в подходах к их использованию. Различные пользователи могут владеть разной терминологией;
• люди, организующие заказы и пользователи – это разные люди. Мнение заказчиков может быть критическим на этом этапе, но они, возможно, не учитывают некоторые потребности пользователей.
Требования клиента можно описать на разных абстрактных уровнях:
• определение требований ( общее описание, которое производится после обсуждения деталей с представителями клиента);
• спецификация требований. Описание, которое использует структурированный и естественный язык и вводит некоторые простые формальные примечания;
• спецификация ПО – завершенное формальное описание требований.
Описание требований должно:
• быть полным и последовательным;
• описывать, как ведет себя система, как она организована;
• рассматривать любые ограничения системы;
• быть легким в развитии;
• принимать во внимание возможные будущие изменения;
• описывать исключения.
Основная ошибка на этом этапе заключается в сосредоточенности на типичных ситуациях и пренебрежении исключениями. И пользователи, и аналитики обладают такой склонностью.
Требования к ПО могут быть разделены на два типа:
• функциональные требования. Они описывают функции (сделки, действия), выполняемые системой;
• нефункциональные требования. Они описывают ограничение функциональности.
Требования должны содержаться в соответствующем документе, который должен включать в себя следующие разделы:
• введение – цели, возможности и контекст системы. Эта часть содержит результаты стратегического этапа;
• описание развития системы – описание возможных изменений;
• описание функциональных требований;
• описание атрофированных требований;
• модель системы;
• словарь.
Кроме того, этот документ может содержать дополнительную информацию:
• спецификация функциональных требований;
• спецификация нефункциональных требований;
• требования к оборудованию;
• требования к базам данных;
• индекс;
• планы тестирования;
Функциональные требования
Функциональные требования описывают выполняемые системой функции. Они могут включать в себя требования к внешним системам.
Часто для описания требований используется неспециализированный язык, при этом возникают некоторые неудобства:
• двусмысленность неспециализированного языка, делает описание трудным к восприятию и может привести к разному его пониманию людьми;
• гибкость неспециализированного языка, позволяющая выражать то же самое содержание в разных формах. Это может привести к упущению противоречивых требований, сформулированных в различных формах одних и тех же функций.
Формальное примечание может устранить двусмысленность, но при этом может оказаться трудным для восприятия клиентом. Таким образом, формальное примечание может только суммировать неспециализированное описание.
Обычно функциональные требования представляются в форме предполагаемого результата, а не в форме алгоритма. Это описание является декларативным, но в некоторых специфических случаях необходимо и изложение алгоритма.
Функциональные требования сформулированы для определения внешних связей. Функции системы должны быть известны пользователям и другим взаимодействующим системам. Под функциями системы мы не должны понимать только функции программы.
Методика декомпозиции функций предполагает, что общие функциональные требования формулируются и делятся по названию функций.
Практически клиенты не всегда понимают или интересуются общими функциональными возможностями системы и обсуждают специфические функции, затем объединенные аналитиком системы. Такую методику называют снизу-вверх.
Большинство разработчиков использует оба метода. Аналитик системы должен рассмотреть сначала общие функции, затем информацию, собранную у пользователей. Таким образом, разделение и объединение описания применяется в процессе формулировки требований.
Нефункциональные требования
Нефункциональные требования описывают ограничения, в которых выполняются функции. Требования могут быть разделены на:
• требования продукта, например "могут использоваться только клавиатура и мышь";
• требования процесса, например "система должна выполняться по стандарту XXA/2002";
• внешние требования, например "система должна работать с базой данных, описанной в документе YYYB/2001, и никакие изменения в базе данных недопустимы".
Эти требования должны быть понятны, то есть должен быть метод проверки выполнения условий. Такие требования как: "удобный", "надежный", "эффективный" не могут быть проверены, следовательно, они не отвечают формулировке.
Для успешной формулировки функциональных требований необходимо:
• постоянное сотрудничество с соответствующими представителями клиента;
• полное понимание требований, осознание особых случаев и исключений в требованиях;
• проверка завершенности и последовательности требований;
• небольшое описание нефункциональных требований.
Анализ
Цель формулирования требований состоит в том, чтобы дать ответ, необходима ли система и какие есть при этом ограничения.
Цель проектирования состоит в том, чтобы определить, как система должна быть реализована.
Цель анализа состоит в том, чтобы определить, как система должна работать. Результатом этого этапа является логическая модель, которая показывает, как подойти к разработке системы. Детали разработки системы не рассматриваются.
Этап анализа также называют этапом моделирования. Логическая модель на этом этапе улучшает понимание системных требований.
Проект начинается с выбора модели в области проблемы и предполагает определение, какова должна быть система. Однако, обязанности системы обычно – подмножество смоделированной модели в анализе.
Факторы успеха при анализе:
• привлечение профессионалов;
• поддержка необходимых стандартов, например, в примечании;
• правильность и проверка концепции;
• прозрачность, логичность и последовательность документации;
• глобальное понимание системы без детализации особенностей.
По результатам анализа получают:
• улучшенный документ по требованиям;
• словарь данных;
• документ, описывающий созданную модель;
• диаграммы класса;
• диаграмма случаев использования;
• диаграмма действий;
• диаграммы состояний;
• отчет, описывающий определение классов, признаков, отношений, методов и т.д.;
• график этапа проектирования;
• предварительное назначение людей и команд.
Продолжение следует...
