лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки
 Скачать 4.41 Mb.
|
неприменима для разработки приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени); неприменима для разработки приложений, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий, скорее всего не будут полностью работоспособны, что в данном случае исключается. Методология XP [7]. Данный подход ориентирован на разработку информационных систем группами малого и среднего размера в условиях неопределенных или быстро изменяющихся требований.Отличительными особенностями XP-разработки являются: частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца); непрерывная связь с заказчиком – в группе все время находится квалифицированный представитель заказчика. Это самое сокровенное желание любого разработчика. Как правило, очень трудно убедить заказчика выделить такого представителя, чтобы он целыми днями (неделями) не выполнял своих прямых обязанностей на работе. Но еще труднее бывает найти именно квалифицированного специалиста, который может оперативно ответить на все увеличивающее количество вопросов со стороны команды разработчиков; простое проектирование – при разработке всегда выбирается наиболее простое решение. «Лучше сделать простую вещь сегодня и завтра заплатить еще немного за внесение небольших изменений, чем делать сегодня сложную вещь, которая завтра может не понадобиться» [7]. Спорное утверждение, на которое можно возразить, что «скупой платит дважды». Нередко опытному разработчику, особенно неплохо разбирающемуся в поставленной задаче, видно, что если применить более сложную схему реализации некоторой функции или расширить структуру данных, то это увеличит круг решаемых задач, позволит с меньшими затратами адаптировать систему под изменяющиеся или новые требования заказчика и т. д.; простой дизайн – система должна быть спроектирована настолько просто, насколько это возможно на каждый момент времени. Чем интерфейс проще, тем быстрее и качественнее идет освоение системы пользователями. Это не означает, что интерфейс «командной строки» самый предпочтительный. Как раз наоборот, «дружественный» и простой интерфейс должен быть интуитивно-понятным для пользователя; в нем должны отсутствовать бесполезные элементы, основная цель которых – произвести визуальное впечатление на пользователя; дополнительные диалоговые окна по вводу данных в строку таблицы, когда это можно сделать непосредственно в строке этой таблицы и т. д.; коллективное владение кодом – любой, кто видит возможность улучшить какую-то часть кода, может сделать это в любой момент времени. Это подразумевает применение одинаковых стандартов и правил оформления кода с исчерпывающими комментариями, а также и ведение общедоступной истории развития системы; программирование в парах – на пару программистов приходится один компьютер. Пока один из них непосредственно программирует, другой обдумывает вопросы реализации требований (функций, БД и т. п.). Смысл положения заключается не в экономии на материально-техническом обеспечении команды разработчиков, а в более разумном сочетании разных видов деятельности каждого из них. Как показывает опыт, при непосредственном программировании, исправлении ошибок и т.п. программист начинает думать односторонне и все более узкими категориями. Именно поэтому во время «отдыха от компьютера» приходят наиболее удачные решения; непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы.Рассмотренные выше методологии направлены на сокращение сроков и расходов по разработке приложений с одновременным повышением качества результатов работы. Главное достоинство этих методологий заключается в наиболее полном и точном удовлетворении требований заказчика за счет обеспечения своевременной обратной связи. Внутренние нормативные документы, регламентирующие требования к коду и порядок отражения результатов рефакторинга Программы для ЭВМ оформляются в соответствии с требованиями Единой системы программной документации (ЕСПД). ЕСПД - набор ГОСТов, устанавливающих правила оформления, содержание, структуру программных документов. Данный how-to содержит выдержки из ЕСПД. Полные сведения можно получить непосредственно из ГОСТов. |