Книга: Технологии программирования
12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ
12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ
Получив некоторое представление о необходимости рассмотрения методологии управления проектом, рассмотрим отдельные ее составляющие: предварительный анализ; четкая формулировка цели; составленные модели данных и словари; выходные формы; безопасность системы и данных; платформа и окружение; контингент будущих пользователей.
Предварительный анализ является очень важным этапом. Вы должны быть уверены, что имеете всю необходимую информацию о клиенте, прежде чем возьметесь за реализацию проекта.
Четкая формулировка цели должна отвечать на вопросы: "Что система должна делать?"; "Была ли четко сформулирована цель создания системы?"; "Знает ли конечный пользователь, что система действительно должна делать?" Конечно, очень важно найти истинную цель приложения, чтобы иметь возможность определить границы проекта. Это необходимо сделать настолько быстро, насколько возможно.
Модели данных и словари необходимы для того, чтобы данные, обрабатываемые в приложении, были выделены и определены в понятиях, доступных как конечным пользователям, так и команде разработчиков. Часто случается, что заранее не существует какой-либо сформировавшейся модели данных, и проектировщик должен создать словарь и модель данных, а затем вернуться к пользователю и оговорить с ним разработанную схему, чтобы пользователь понимал ее.
Выходные формы. При предварительном опросе пользователя необходимо сделать наброски всех выходных форм, поскольку может потребоваться дополнительное наращивание словаря для обеспечения реализации того или иного.
Безопасность системы и данных. Прежде чем начать разработку, конечный пользователь должен определить необходимость обеспечения безопасности системы и данных. Включение системы обеспечения безопасности должно рассматриваться на самой ранней стадии проектирования.
Платформа и окружение. Важно оценить окружение, в котором будет работать система. Клиенты тратят большие средства на приобретение аппаратных средств еще до того, как обращаются к вам. Вы должны выяснить все детали: о сетевых аппаратных и программных ресурсах; о типах компьютеров; об операционной системе; о типах принтеров, мониторов, дисководов, других периферийных устройств.
Контингент будущих пользователей. Часто понятие "кто" значительно важнее понятия "что". Хорошее понимание категорий конечных пользователей может дать вам важную стартовую информацию для начала создания проекта. Вы должны постоянно изучать, что хотят ваши конечные пользователи. Различные типы пользовательских групп имеют различные требования, которые должны быть учтены при проектировании программного обеспечения.
Если вы делаете приложения для общего рынка, то можете создать только очень грубое представление о конечном пользователе. Если вы пишите какую-либо общую программу учета, то можете лишь предположить, что мой клиент имеет общее представление о компьютере и у него есть необходимость что-либо учитывать.
Если вы пишите программу поддержки офиса бюро путешествий и экскурсий, то знаете, что конечные пользователи будут использовать данное приложение именно в этой области. Таким образом, вы можете оптимизировать систему учета и расчетов, учитывая конкретную специфику. Однако вы не знаете ни опыта работы конечных пользователей с вычислительной техникой, ни уровня их профессионализма в их собственном бизнесе.
Если вы пишете пользовательское приложение, например офисную систему для офиса "Иванов и сыновья", то можете непосредственно общаться с конечными пользователями и выяснять их уровень познания вычислительной техники и опыт работы в собственном бизнесе, что даст возможность разработчику заранее предусмотреть большинство конфликтных ситуаций между вашим приложением и конечными пользователями.
Что ожидают от вас конечные пользователи?
Каждая группа конечных пользователей имеет различные требования и ожидания от вашей системы. Перед началом проектирования системы необходимо выяснить, на что рассчитывает конечный пользователь. Необходимо обратить внимание на следующие аспекты: начальное обследование и составление технического задания, инсталляция, обучение, поддержка, помощь в эксплуатации.
Резюме. Как проектировщик системы, вы должны вернуться на уровень предварительного анализа задачи и удостовериться, что вся необходимая информация вами получена. При несоблюдении данного требования вы можете значительно замедлить реализацию проекта вследствие многократного повторного обращения к пользователю за уточнением неверно трактованных деталей и необговоренных условий.
- 12.1. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ СИСТЕМ
- 12.2. СТРУКТУРА УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ СРЕДСТВ
- 12.3. ПОДБОР КОМАНДЫ
- 12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ
- 12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ
- 12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА
- 12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ
- 12.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ
- 12.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
- 12.10. РЕАЛИЗАЦИЯ
- 12.11. СИСТЕМНОЕ ТЕСТИРОВАНИЕ
- 12.12. ПРИЕМОЧНЫЙ ТЕСТ
- 12.13. ПОСЛЕРЕАЛИЗАЦИОННЫЙ ОБЗОР
- 12.14. СОПРОВОЖДЕНИЕ ПРОГРАММ
- 1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ
- 3. Участники разработки экспертных систем
- Часть III. Шаблоны разработки через тестирование
- 1.1. Схема и основные этапы разработки новой продукции
- 5.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССА "КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ"
- IBPP для разработки C++
- 7.2. Этапы разработки
- Процесс разработки программного обеспечения
- Дополнительные средства разработки .NET-приложений
- Методологии внедрения SAP
- Установка библиотек разработки GNOME
- 1.2. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММ