|
 Важной частью любого проекта по разработке программного обеспечения является сбор требований. Если вам не совсем ясно то, что вы собираетесь предоставить, то как вы поймете, что вы уже завершили реализацию проекта? Качественные требования клиентов приведут к лучшим прогнозам, большей удовлетворенности клиентов, сниженным затратам и коротким срокам.
Несколько вопросов, которые вам стоит задать при любом проекте по разработке ПО: - Почему вы создаете данную систему?
- Какие преимущества вы ожидаете получить от ее реализации?
- Что на самом деле она должна выполнять ?
Неудачный сбор требований или предположение того, что вы знаете, что требуется клиенту, приведет вас к скудным результатам, необходимости в дополнительных ресурсах, увеличенным затратам и срокам. Как говорит Брукс, "наиболее тяжелой частью создания системы программного обеспечения является решение о том, что вы собираетесь создавать. Никакая другая часть работы не может настолько навредить созданию системы, как эта, в том случае, если она неверна. Любую другую часть легче исправить, нежели эту." Предоставление стойкой основы Хороший сбор требований клиентов предоставляет основательный фундамент для последующей работы. Клиенты должны знать о том, что будет разработано и что оно удовлетворит их требования. Разработчики должны понимать, что они будут разрабатывать, а тестеры - тестировать. Качественный документ с требованиями может предоставить все это. При создании данного документа вам стоит вовлечь всех, включая клиентов, руководителей проектов, разработчиков, тестеров, дизайнеров и любого, кто имеет отношению к проекту. Сбор требований - это совместная деятельность, а не только забота бизнес-аналитиков и руководителей проектов. Хороший набор требований позволяет руководителю проектов эффективно осуществлять планирование и прогнозы. Организация встреч по сбору требований Встречи по сбору требований - это именно то время, когда собираются все члены команды, клиенты и участники для определения требований к системе. Как и на других формальных встречах, здесь также требуется повестка дня. Вам необходимо обсудить несколько вещей за время данных собраний: - Ознакомление с людьми, участвующими в собрании
- Цели собрания
- Назначение проекта
- Ожидаемые результаты и выгоды
- Требования клиентов
- Следующие шаги
В идеале, бизнес-аналитик должен вести открытое собрание, где все идеи нацелены на изучение требований клиентов. Клиенты не всегда могут хорошо описать свои требования, поэтому вам стоит повторно изучить ваше понимание их требований для обеспечения ясности. Вам может понадобиться организовать несколько встреч для сбора требований. Требования должны быть написаны бизнес-аналитиком в документе спецификации бизнес-требований и затем продемонстрированы клиентам. Документ должен быть ясным, четким и полноценным. Клиент должен изучить и одобрить содержимое документа. Вам не всегда стоит настаивать на письменном соглашении, так как это может быть воспринято как недостаток доверия, и проект может начаться с неподходящей ноты. Включая сценарии использования в спецификации бизнес-требований, вам стоит также задокументировать бизнес-процессы и определить различные роли в процессе. Клиентам зачастую легче понять диаграммы, нежели текст. Существуют некоторые правила написания документов с требованиями: - Требования должны быть написаны на языке пользователя
- Вам стоит избегать технического сленга
- Уточните то, что система не будет делать, а также то, что она будет выполнять
- Выражайте мысли полно, четко, ясно
- Вам стоит уделить время и на нефункциональные требования
Зачем нужны требования ? Существует несколько причин для сбора требований: - Собрать все идеи и мысли логичным способом
- Собрать чьи то мыли и идеи логичным способом
- Осознать то, что пакет приложений должен делать до принятия решения
- Принять решение о том, стоит ли вам покупать или создавать
- Требования будут являться опорной точкой на протяжении всего проекта
- Предоставить основы для тестирования
Распространенные проблемы Существуют некоторые распространенные проблемы при выполнении сбора требований: - На это нет времени из-за кратчайших сроков
- У клиента нет возможности встречаться и обсуждать требования
- Сбор требований кажется пустой тратой времени для организации
- Уверенность в том, что нам известны нужды клиентов, и нет необходимости их об этом спрашивать
- Не существует способа эффективно записать требования
- Отсутствие желания собирать требования
Разработка прототипа Когда клиентам сложно огласить свои требования, то разработка прототипа является недорогим способом помочь им представить потенциальное решение. Зачастую клиенты не уверены в том, что им на самом деле нужно (в частности, относительно проектов по разработке ПО), и прототип может помочь понять эти требования. Вам может понадобиться доказать принципы работы в случае, если технологии инновационные, или если проектная команда незнакома с ними. Доказательство принципов подтвердит возможность информационного отдела предоставить требуемое решение. Проектирование системы Как только вы установите и обговорите весь набор требований, следующим шагом будет модель ПО. Использование общеизвестной нотации может оказаться очень полезным на данном этапе и поможет команде создать четкий и точно выраженный документ дизайна ПО. До того, как вы приступите к созданию решения, проверьте вашу разработку на соответствие с требованиями для того, чтобы обеспечить исполнение нужд клиента. Пересматривайте документ регулярно для того, чтобы проект не сошел с установленного пути. Моделируйте программное обеспечения до начала его реализации. Унифицированная модель (UML) - популярная нотация для создания моделей объектно-ориентированного ПО. Унифицированный язык моделирования (UML - Unified Modeling Language) Развитие унифицированного языка моделирования (UML) началось в октябре 1994 и представляет собой консолидацию принципов и системы обозначений Гради Буча, Джеймса Рамбо и Айвара Якобсона. UML - это независящая от технологий нотация, используемая для моделирования систем при помощи объектно-ориентированных парадигм. Данная нотация также может быть определена как стандартный язык для указания, визуализации, построения и документации всех артефактов системы программного обеспечения. UML 2.0 состоит из тринадцати типов диаграмм, разделенных на структуры, поведение и взаимодействия. Диаграммы структур акцентируют внимание на том, что должно быть включено в моделируемую систему: - Диаграмма классов (Class)
- Диаграмма компонентов (Component)
- Диаграмма объектов (ObjecT)
- Диаграмма композитных структур (Composite structure)
- Диаграмма развёртывания (Deployment)
- Диаграмма пакетов (Package)
Диаграммы поведения уделяют внимание тому, что должно произойти в моделируемой системе: - Диаграмма деятельности (Activity)
- Диаграмма сценариев использования (Use Case)
- Диаграмма автомата (State Machine)
Диаграммы взаимодействия - это подмножество диаграмм поведения, которые акцентируют внимание на процессе управления и потоке данных среди прочего, где будет разработана система: - Диаграммы последовательностей (Sequence)
- Диаграмма коммуникации (Communication - UML 2.0)
- Диаграмма обзора взаимодействия (Interaction Overview - UML 2.0)
- Диаграмма синхронизации (Timing - UML 2.0)
Язык UML принят компанией OMG, разработчиком объектно-ориентированных вычислительных систем, в качестве стандарта моделирования объектно ориентированных программ. Так же, как и для разработки ПО, UML-нотации могут быть пригодны на этапе сбора требований. К примеру, диаграмма сценариев использования покажет пользователям то, что они должны сделать, а также что система может сделать для них. Диаграммы также могут быть использованы в качестве основы для тестирования приложения (создания планов тестирования) и разработки руководства пользователя. Хорошие модели обеспечивают техническую и архитектурную прочность, в частности для сложных систем. Критические факторы успеха Для того чтобы успешно собрать требования и придать вашим проектам по разработке ПО увеличенную вероятность в успехе, вы должны: - Не подразумевать, что вы знаете, чего хочет, требует ваш клиент
- Вовлекать пользователей с самого начала
- Определить и обговорить масштаб проекта
- Убедиться в том, что требования четкие, конкретные, реалистичные и измеримые
- Обеспечить ясность в случае возникновения сомнений
- Создать ясный, четкий и полный документ требований и огласить его клиентам
- Подтвердить ваше понимание требований, повторно обсудив их с клиентом
- Избегать технических разговоров до того, как требования будут полностью поняты
- Получить все требования, обговоренные с клиентами, до того, как начнется проект
- Создать прототип в случае, если необходимо подтвердить или пересмотреть клиентские требования
- Использовать общепринятую нотация, такую как язык UML, для моделлирования ПО
- Проверить разработку ПО сравнив результаты с требованиями на постоянной основе
Факты о языке UML - Разработка унифицированного язык моделирования UML началась в октябре 1994
- На данный момент стандартом является UML 2.0, в котором приведены значительные изменения
- UML представляет собой собрание принципов и нотаций Гради Буча, Джеймса Рамбо и Айвара Якобсона.
- UML принят группой OMG в качестве стандарта моделирования объектно-ориентированных программ
- UML - это популярная нотация для создания моделей объектно-ориентированного ПО
- UML - это независимая технология и она может быть использована для любого типа разработки ПО
- Существуют конкретные инструменты разработки на языке UML, но диаграммы могут быть созданы такими ПО как MS Visio
- UML принадлежит группе OMG, а не компании Rational, как кажется многим
Duncan Haughey, PMP
Newer news items:
Older news items:
|
