Все члены команды точно знают свои обязанности. Это достигается с помощью встреч (сессий), на которых обсуждаются отдельные части проекта. В каждый момент времени на определенной стадии проекта все члены команды знают точно, что они должны делать. Это достигается с помощью постановки задач и определения локальных заданий.
Определенная методология разработки программного обеспечения устраняет разногласия и отсутствие связи между членами команды разработчиков и между программистами и конечными пользователями.
Новые люди "безболезненно" подключаются к проекту на любой стадии разработки.
Конечное приложение базируется на фундаментальном анализе задачи, что позволяет свести к минимуму затраты на дальнейшую доработку, модификацию и сопровождение продукта.
В процессе разработки создается мощный пакет документации, позволяющий в дальнейшем упростить неизбежное сопровождение и дополнения программного продукта.
12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ
Получив некоторое представление о необходимости рассмотрения методологии управления проектом, рассмотрим отдельные ее составляющие: предварительный анализ; четкая формулировка цели; составленные модели данных и словари; выходные формы; безопасность системы и данных; платформа и окружение; контингент будущих пользователей.
Предварительный анализ является очень важным этапом. Вы должны быть уверены, что имеете всю необходимую информацию о клиенте, прежде чем возьметесь за реализацию проекта.
Четкая формулировка цели должна отвечать на вопросы: "Что система должна делать?"; "Была ли четко сформулирована цель создания системы?"; "Знает ли конечный пользователь, что система действительно должна делать?" Конечно, очень важно найти истинную цель приложения, чтобы иметь возможность определить границы проекта. Это необходимо сделать настолько быстро, насколько возможно.
Модели данных и словари необходимы для того, чтобы данные, обрабатываемые в приложении, были выделены и определены в понятиях, доступных как конечным пользователям, так и команде разработчиков. Часто случается, что заранее не существует какой-либо сформировавшейся модели данных, и проектировщик должен создать словарь и модель данных, а затем вернуться к пользователю и оговорить с ним разработанную схему, чтобы пользователь понимал ее.
Выходные формы. При предварительном опросе пользователя необходимо сделать наброски всех выходных форм, поскольку может потребоваться дополнительное наращивание словаря для обеспечения реализации того или иного.
Безопасность системы и данных. Прежде чем начать разработку, конечный пользователь должен определить необходимость обеспечения безопасности системы и данных. Включение системы обеспечения безопасности должно рассматриваться на самой ранней стадии проектирования.
Платформа и окружение. Важно оценить окружение, в котором будет работать система. Клиенты тратят большие средства на приобретение аппаратных средств еще до того, как обращаются к вам. Вы должны выяснить все детали: о сетевых аппаратных и программных ресурсах; о типах компьютеров; об операционной системе; о типах принтеров, мониторов, дисководов, других периферийных устройств.
Контингент будущих пользователей. Часто понятие "кто" значительно важнее понятия "что". Хорошее понимание категорий конечных пользователей может дать вам важную стартовую информацию для начала создания проекта. Вы должны постоянно изучать, что хотят ваши конечные пользователи. Различные типы пользовательских групп имеют различные требования, которые должны быть учтены при проектировании программного обеспечения.
Если вы делаете приложения для общего рынка, то можете создать только очень грубое представление о конечном пользователе. Если вы пишите какую-либо общую программу учета, то можете лишь предположить, что мой клиент имеет общее представление о компьютере и у него есть необходимость что-либо учитывать.
Если вы пишите программу поддержки офиса бюро путешествий и экскурсий, то знаете, что конечные пользователи будут использовать данное приложение именно в этой области. Таким образом, вы можете оптимизировать систему учета и расчетов, учитывая конкретную специфику. Однако вы не знаете ни опыта работы конечных пользователей с вычислительной техникой, ни уровня их профессионализма в их собственном бизнесе.
Если вы пишете пользовательское приложение, например офисную систему для офиса "Иванов и сыновья", то можете непосредственно общаться с конечными пользователями и выяснять их уровень познания вычислительной техники и опыт работы в собственном бизнесе, что даст возможность разработчику заранее предусмотреть большинство конфликтных ситуаций между вашим приложением и конечными пользователями.
Что ожидают от вас конечные пользователи?
Каждая группа конечных пользователей имеет различные требования и ожидания от вашей системы. Перед началом проектирования системы необходимо выяснить, на что рассчитывает конечный пользователь. Необходимо обратить внимание на следующие аспекты: начальное обследование и составление технического задания, инсталляция, обучение, поддержка, помощь в эксплуатации.
Резюме. Как проектировщик системы, вы должны вернуться на уровень предварительного анализа задачи и удостовериться, что вся необходимая информация вами получена. При несоблюдении данного требования вы можете значительно замедлить реализацию проекта вследствие многократного повторного обращения к пользователю за уточнением неверно трактованных деталей и необговоренных условий.
12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА
Существует огромная пропасть между идеями пользователей и представлением о возможных способах реализации этих идей конкретными разработчиками. Мостом между этими двумя понятиями должен быть первичный этап обследования проекта и составление технического задания на данный проект. Эта задача делится на три стадии: изучение требований заказчика, уточнение функциональной специфики задачи и техническое проектирование задачи.
Анализ требований и пожеланий заказчика начинается с получения заказа на новую разработку (или на модификацию существующей) и заканчивается составлением документа, в деталях описывающего данную разработку. Это должен быть интерактивный процесс, в результате которого появляется документ, полностью описывающий задачу и удовлетворяющий обе стороны, включающий рассмотрение всех проблем и решаемых задач, множество листов с требованиями и пожеланиями заказчика и прочую необходимую информацию.
Наиболее важная цель, которой необходимо достигнуть на этом первом этапе, — это найти и понять, что же НА САМОМ ДЕЛЕ ХОЧЕТ ПОЛЬЗОВАТЕЛЬ. Иной раз сделать это не так просто, поскольку пользователь не всегда точно представляет, ЧТО он действительно хочет получить. Банальным примером могут служить пользователи, заказывающие, например, одновременно несколько больших задач типа "Учет заработной платы", "Ведение складского учета", "Составление табеля" и т. п., называя все это "Бухгалтерией". Если проигнорировать данный этап, то проект может в конце концов быть осужден на большое количество доработок, достраивание кода "на коленке" и непременное сидение программистов по выходным, чтобы сделать клиенту действительно то, что он хочет и что не было оговорено заранее.
Очевидно, что любой проект начинается с идеи. Как только появляется идея, один или несколько человек начинают ее развивать. Эти люди — заказчики или потенциальные пользователи. Они определяют начальные требования и принимают решение о создании того или иного программного продукта. Таким образом, необходимо выяснить, что же эти люди хотят получить от программного продукта.
Перед началом обсуждения будущего проекта очень важно убедиться, что с обеих сторон стола переговоров сидят именно те люди, которые требуются для совместного обсуждения проекта. Три наиболее распространенные ошибки допускаются на данном этапе.
Ошибка 1. Пользователи, начинающие обсуждение проекта, не являются людьми, которые будут принимать окончательное решение о требованиях к обсуждаемой системе (т. е. они не являются людьми, имеющими полное представление об описываемой ими задаче).