Er ad ошибки внутреннего преобразования - Не ошибается лишь тот, кто ничего не делает!

Один из подходов
к разработке ПО в рамках спиральной
модели ЖЦ – получившая широкое
распространение методология (технология)
быстрой разработки приложений RAD (Rapid
Application
Development)
[6]. Данная модель очень хорошо подходит
к разработке учебных программ, т.к.
включает в себя три составляющие:

небольшую команду
программистов (от 2 до 10 человек);
короткий, но
тщательно проработанный производственный
график (от 2 до 6 мес.);
повторяющийся
цикл, при котором разработчики по мере
того, как приложение начинает обретать
форму, запрашивают и реализуют в продукте
требования, полученные через взаимодействие
с заказчиком.

Рассмотрим данную
модель более подробно. Команда
разработчиков должна представлять
собой группу профессионалов, имеющих
опыт в анализе, проектировании, генерации
кода и тестировании ПО с использованием
CASE-средств, способных хорошо
взаимодействовать с конечными
пользователями и трансформировать их
предложения в рабочие прототипы.
Жизненный цикл ПО по методологии RAD
состоит из четырёх фаз (рисунок 21):

Анализа и
планирования требований;
Проектирования;
Построения;
Внедрения.

На первой фазе
анализа и планирования
требований пользователи
системы определяют функции, которые
она должна выполнять, выделяют наиболее
приоритетные из них, требующие проработки
в первую очередь, описывают информационные
потребности (связи). Формулирование
требований к системе осуществляется в
основном силами пользователей под
руководством специалистов-разработчиков.
Ограничивается масштаб проекта,
устанавливаются временные рамки для
каждой из последующих фаз. Кроме того,
определяется сама возможность реализации
проекта в заданных размерах финансирования,
на имеющихся аппаратных средствах и
т.п.

Результатом фазы
должны быть: список расставленных по
приоритету функций будущей ПС;
предварительная функциональная модель
ПС; предварительная информационная
модель ПС.

На второй фазе
проектирования
часть пользователей принимают участие
в техническом проектировании системы
под руководством специалистов-разработчиков
и, взаимодействуя с ними, уточняют и
дополняют требования к системе, которые
не были выявлены на предыдущей фазе.
Более подробно рассматриваются процессы
системы. При необходимости корректируется
функциональная модель, создаются
частичные прототипы: экранов, отчетов,
устраняющие неясности или неоднозначности.
Устанавливаются требования разграничения
доступа к данным. На этой же фазе
происходит определение необходимой
документации. После детального определения
состава процессов оценивается количество
функциональных элементов разрабатываемой
системы и принимается
решение о разделении системы на
подсистемы.

Результатом
данной фазы должны быть: общая
информационная модель системы;
функциональные модели системы в целом
и подсистем; точно определенные интерфейсы
между автономно разрабатываемыми
подсистемами; построенные прототипы
экранов, отчетов, диалогов.

В отличие от
традиционного подхода, при котором
использовались специфические средства
прототипирования, не предназначенные
для построения реальных приложений, а
прототипы выбрасывались после того,
как выполняли задачу устранения
неясностей в проекте, в подходе RAD
каждый прототип развивается в часть
будущей системы. Таким образом, на
следующую фазу передается более полная
и полезная информация.

На третьей фазе
построения
выполняется непосредственно сама
быстрая разработка приложения (реализация
подсистем). На данной фазе разработчики
производят итеративное построение
реальной системы на основе полученных
в предыдущей фазе моделей, а также
требований нефункционального характера.
Конечные пользователи на этой фазе
оценивают получаемые результаты и
вносят коррективы, если в процессе
разработки система перестает удовлетворять
определенным ранее требованиям.
Тестирование системы осуществляется
в процессе разработки.

После окончания
разработки подсистем производится
постепенная интеграция данной части
системы с остальными, формируется полный
программный код, выполняется тестирование
системы в целом. Завершается физическое
проектирование системы: определяется
необходимость распределения данных;
осуществляется анализ использования
данных; производится физическое
проектирование базы данных; определяются
требования к аппаратным ресурсам;
определяются способы увеличения
производительности; завершается
разработка документации проекта.

Результатом фазы
является готовая система, удовлетворяющая
всем согласованным требованиям.

На четвертой
фазе внедрения
производятся обучение пользователей,
организационные изменения и параллельно
с внедрением новой системы осуществляется
работа с существующей системой ( до
полного внедрения новой ). Так как
фаза построения достаточно непродолжительна,
планирование и подготовка к внедрению
должны начинаться заранее, как правило,
на этапе проектирования системы.

Технология RAD
(как и любая другая) не может претендовать
на универсальность, она хороша в первую
очередь для относительно небольших
проектов, разрабатываемых для конкретного
заказчика. Она неприменима для разработки
операционных систем; сложных расчетных
программ с большим объемом программного
кода и сложными уникальными алгоритмами
управления; приложений, в которых
отсутствует ярко выраженная интерфейсная
часть, наглядно определяющая логику
работы системы (приложения реального
времени), так как итерационный подход
предполагает, что несколько первых
версий не будут полностью соответствовать
требованиям.

В заключение
перечислим основные принципы технологии
RAD:

разработка
приложений итерациями;
необязательность
полного завершения работ на каждом
этапе ЖЦ;
обязательное
вовлечение пользователей на этапе
разработки;
использование
прототипирования, позволяющего выяснить
и удовлетворить все требования конечного
пользователя;
тестирование и
развитие проекта одновременно с
разработкой;
грамотное
руководство разработкой, четкое
планирование и контроль выполнения
работ.

Контрольные
вопросы к главе 3:

Что такое
стандартизация и сертификация
программного продукта?
Какие существуют
типы стандартов?
Перечислите
наиболее известные стандарты жизненного
цикла, которые использовались для
разработки программного обеспечения?
Что такое жизненный
цикл ПО?
Перечислите
основные этапы жизненного цикла ПО.
Что такое процесс, действие, задача?
Какие типы процессов
и конкретные процессы вы запомнили?
Расскажите об
основных инженерных процессах жизненного
цикла ПО.
Что такое модель
жизненного цикла ПО? Дайте определения
основных понятий, связанные с понятием
«модель».
Какие типы моделей
вы знаете? В чем их преимущества,
недостатки, область применимости?
Что вы можете
сказать об особенностях каскадной
модели жизненного цикла?
В чем отличие
обобщенной каскадной модели от базовой?
Что вы можете
сказать об особенностях спиральной
модели жизненного цикла?
Перечислите
составляющие технологии RAD.
Для разработки каких типов ПО можно
применять технологию RAD?
Опишите основные
фазы жизненного цикла по технологии
RAD.
Перечислите
основные принципы технологии RAD.

СПИСОК ЛИТЕРАТУРЫ

Аптекарь М. Д.,
Рамазанов С. К., Фрегер Г. Е.
История инженерной деятельности. –
Киев, 2003. – 204 с. : ил.
Арчибальд Р.
Модели жизненного цикла высокотехнологичных
проектов.
http://www.pmprofy.ru/content/rus/107/1073-article.html
Брукс Ф.
Мифический человеко-месяц или как
создаются программные системы. – СПб.
: Символ-плюс, 1999. – 321 с. : ил.
Буч Г.
Объектно-ориентированное проектирование
с примерами применения. – М.: Конкорд,
1992. – 586с. : ил.
Буч Г.
Объектно-ориентированный анализ и
объектно-ориентированное проектирование
на С++. – М. : Бином, – 2001. – 558 с.
: ил.
Вендров А. М.
CASE-технологии.
Современные методы и средств
проектирования информационных систем.
– М. : Финансы и статистика, – 1999. –
256 с. : ил.
Вирт
Н. Алгоритмы + структуры данных = программы
: Пер. с англ. – М. : Мир, 1985. – 406 с.:
ил.
Дал О., Дейкстра Э.,
Хоор К. Структурное программирование:
Пер. с англ. – М.: Мир, 1975. – 247 с. : ил.
Дзержинский Ф. Я.,
Калиниченко И.М. Дисциплина
программирования : концепция и опыт
реализации методических средств
программной инженерии. – М.: ЦНИИ
информации и технико-экономических
исследований по атомной науке и
технике, 1988. – 245 с. : ил.
Жоголев
Е. А. Технологии программирования.
– М. : Научный мир, 2004. – 216 с. : ил.
Закон
РФ № 149-ФЗ от 29.07.2006. «Об информации,
информационных технологиях и защите
информации»// Российская газета, № 165
от 27.07.2006 г.
Иванова Г. С.
Технология программирования: Учебник
для вузов. – 2-е изд., стереотип. – М. :
Изд-во МГТУ им. Н.Э.Баумана, 2003. – 320 с.:
ил.
Калянов Г. Н.
CASE: Структурный системный анализ
(автоматизация и применение). – М. :
«Лори», 1996. – 356 с. : ил.
Кораблин М. А.
Программирование, ориентированное
на объекты: Учебное пособие. – Самара:
изд-во СГАУ, 1994. – 94 с.
Леоненков А. В.
Самоучитель UML.
– СПб : ВХВ Петербург, – 2001. – 304 с. :
ил.
Липаев В. В.
Качество программного обеспечения.
– М.: Финансы и статистика, 1983. – 263 с.
: ил.
Липаев В. В.
Отладка сложных программ: Методы,
средства, технология. –М. :
Энергоатомиздат, 1993. – 384 с. : ил.
Липаев В. В.,
Филиппов Е. Н. Мобильность программ
и данных в открытых информационных
системах. – М. : Научная книга, 1997. –
297 с. : ил.
Майерс Г.
Надежность программного обеспечения.
– М. : Мир, 1980. – 375 с. : ил.
Ожегов С. И.
Словарь русского языка. – М. : Мир и
образование, 2006. – 1328 с.
Технология
проектирования комплексов программ
АСУ/ В. В. Липаев, Л. А. Серебровский,
П. Г. Гаганов и др.; Под ред.
Ю. В. Афанасьева, В. В. Липаева.
– М. : Радио и связь, 1983. – 256 с. : ил.
Хювенен
Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск.
В 2 т. Т.1 : Введение в язык Лисп и
функциональное программирование.–
М. : Мир, 1990. – 447 с. : ил.
Хювенен
Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск.
В 2 т. Т.2 : Методы и системы программирования.–
М. : Мир, 1990. – 319 с. : ил.
Boehm B.«A
Spiral Model of Software Development and Enhancement»,
IEEE Computer, Vol. 21, No. 5, pp. 61–72, 1988.
Courtois
P. June 1985. On Time and Space Decomposition of Complex
Structures. Communications of the ACM vol.28(6), p.596.
Criteria
for Evaluation of Software. ISO TC97/SC7 #383.
Dijktra
E. 1979. Programming Considered as a Human Activity. Classics in
Software Engineering. New York, NY: Yourdon Press.
http://www.pmi.ru/glossary/.
http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.
Microsoft
Corporation.
Принципы проектирования и разработки
программного обеспечения. Учебный
курс MCSD:
Пер. с англ. – М.: Издательско-торговый
дом «Русская редакция», 2000. –608 с. : ил.
Parnas D.,
Clements P., Weiss D. 1983. Enhancing Reusability with
Information Hiding. Proceedings of the Workshop on Reusability in
Programming. Stratford, CT: ITT Programming.
p.241.
Rechtin
E. October 1992. The Art of Systems Architecting. IEEE Spectrum,
vol.29 (10),
p.66.
Royce W.W.
Managing the Development of Large Software Systems.
http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.
Shaw
M. October 1984. Abstraction Techniques in Modern Programming
Languages. IEEE Software vol.1 (4).
Simon
H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT
Press. – p.218.
Sommerville I.
Software engineering. – Addison-Wesley Publishing Company, 1992.
p.87.
Tesler
L. August 1981. The Smalltalk Environment. Byte vol.6(8),
p.142.
Yonezawa A.,
Tokoro M. 1987. Objectt-Oriented
Concurrent Programming. Cambridge, MA: The MIT Press.

список терминов

Название термина	Определение
Русское	Английское
Абстракция	Abstraction	Существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя
Алгоритм	Algorithm	Заранее заданная последовательность четко определенных правил или команд для получения решения задачи за конечное число шагов
Алгоритмическая декомпозиция	Algorithmic decomposition	Процесс разделения системы на части, каждая из которых отражает этап общего процесса. Применение структурного подхода к проектированию приводит к алгоритмической декомпозиции, которая фокусируется на потоке управления в системе
Верификация	Verification	Процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа
Данные	Data	Представление фактов и идей в формализованном виде, пригодном для передачи и переработки в некоем процессе
Жизненный цикл программы	Software Lifetime Cycle	Непрерывный процесс, который начинается с момента принятия решения о необходимости создания программы и заканчивается в момент ее полного изъятия из эксплуатации
Иерархия	Hierarchy	Упорядочение абстракций, расположение их по уровням. В терминах иерархии «часть/целое» объект находится на более высоком уровне абстракции, чем другие, если он строится на основе этих объектов; в терминах иерархии «общее/частное» высокоуровневые абстракции носят более обобщенный характер, чем низкоуровневые
Инкапсуляция	Encapsulation	Объединение в классе данных (свойств) и методов (процедур обработки), сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей
Информационная среда	Data medium	Совокупность носителей данных, используемых при какой-либо обработке данных
Носитель данных	Материал с определенными физическими свойствами, который может использоваться для хранения данных (магнитные лента или диск, оптический диск, бумага для распечатки)
Информация	Information	Смысл, который придается данным при их представлении
Сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления
Качество программы	Software quality	Совокупность черт и характеристик программной системы, которые влияют на ее способность удовлетворять заданные потребности пользователей
Класс	Class	Множество объектов, обладающих внутренними (имманентными) свойствами, которые играют роль классообразующих признаков и присущи любому объекту класса
Методология программирования	Methodology of programming	Совокупность механизмов, применяемых в процессе разработки программного обеспечения и объединенных одним общим философским подходом
Модель	Model	Абстракция, которая служит для упрощения или представления какой-либо концепции или процесса
Модель жизненного цикла	Life cycle model	Описывается набор фаз (этапов, стадий) проекта по созданию продукта, в которых выполняются отдельные процессы, разбитые на операции и задачи
Модуль	Module	Единица кода, служащая строительным блоком физической структуры системы; программный блок, который содержит объявления, выраженные в соответствии с требованиями языка и образующие физическую реализацию части или всех классов и объектов логического проекта системы (состоит из интерфейсной части и реализации)
Модульное программирование	Modular programming	Организация программы в виде совокупности модулей со строгим соблюдением правил их взаимодействия
Надежность	Reliability	Способность системы программного обеспечения выполнять возложенные на нее функции при поступлении требований на их выполнение
Наследование	Inheritance	Возможность вывода нового класса из старого с частичным изменением свойств и методов
Отношение между классами, при котором класс использует структуру или поведение другого (одиночное наследование) или других (множественное наследование) классов. Наследование вводит иерархию «общее/частное», в которой подкласс наследует от одного или нескольких более общих суперклассов. Подклассы обычно дополняют или переопределяют унаследованную структуру и поведение
Обработка данных	Data processing	Выполнение систематической последовательности действий с данными, которые представляются и хранятся на так называемых носителях данных
Объектная модель	Object model	Совокупность основополагающих принципов, лежащих в основе объектно-ориентированного проектирования; парадигма программирования, основанная на принципах абстрагирования, инкапсуляции, модульности, иерархичности, типизации, параллелизма и устойчивости
Объектное программирование	Object-based programming	Метод программирования, основанный на представлении программы как совокупности объектов, каждый из которых является экземпляром некоторого типа. Типы образуют иерархию, но не наследственную. В программах типы рассматриваются как статические, а объекты имеют более динамическую природу, которую ограничивают статическое связывание и мономорфизм
Объектно-ориентированная декомпозиция	Object-oriented decomposition	Процесс разбиения системы на части, соответствующие классам и объектам предметной области. Мир рассматривается как совокупность объектов, согласованно действующих для обеспечения требуемого поведения
Объектно-ориентированное программирование	Object-oriented programming	Методология реализации, при которой программа организуется, как совокупность объектов, каждый из которых является экземпляром какого-либо класса, а классы образуют иерархию наследования. При этом классы обычно статичны, а объекты очень динамичны, что «поощряется» динамическим связыванием и полиморфизмом
Объектно-ориентированное проектирование	Object-oriented design	Методология проектирования, соединяющая процесс объектно-ориентированной декомпозиции и систему обозначений для представления логической и физической, статической и динамической моделей проектируемой системы. Система обозначений состоит из диаграмм классов, объектов, модулей и процессов
Парадигма программирования	Paradigm	Новая модель конструирования программы и взаимодействия ее с данными
Полиморфизм	Polymorphism	Определение свойств и методов объекта по контексту (подразумевает отделение идеи «что делать» от ее воплощения внутри иерархии класса объектов «как делать»)
Положение теории типов, согласно которому имена (например, переменных) могут обозначать объекты разных (но имеющих общего родителя) классов. Следовательно, любой объект, обозначаемый полиморфным именем, может по-своему реагировать на некий общий набор операций
Предметная область	Application domain	Часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы, она включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения некоторой задачи
Программа	Program	Набор операторов, который может быть представлен как единое целое в некоторой вычислительной системе и который используется для управления поведением этой системы.
Программирование (в широком смысле)	Programming	Все технические операции, необходимые для создания программы, включая анализ требований и все стадии разработки и реализации
Программирование (в узком смысле)	Процесс кодирования и отладки программы в рамках реального проекта
Программная инженерия	Software engineering	Систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств
Процесс	Process	Набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты
Процесс разработки	development process	В соответствии со стандартом предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с созданными требованиями, включая оформление проектной и эксплуатационной документации, а также подготовку материалов, необходимых для проверки работоспособности и соответствия качества программных продуктов, материалов, необходимых для обучения персонала, и т.д.
Сопровождаемость	Maintainability	Характеристики ПС, которые позволяют минимизировать усилия по внесению изменений в систему при устранении в ней ошибок и/или при ее модификации из-за изменяющихся потребностей пользователей
Среда разработки	Framework	Набор классов, предоставляющих некоторые базовые услуги в определенной области. Таким образом, среда разработки экспортирует классы и механизмы, которые клиенты могут использовать или адаптировать в своих целях
Стандарт	Standard	Нормативно-технический документ, утверждаемый компетентным органом, устанавливающий комплекс норм, правил по отношению к предмету стандартизации; типовой образец, эталон, модель, которые принимаются как исходные для сопоставления с ними других предметов
Структурное программирование	Structured programming	Методология программирования, основанная на предположении, что логичность и понятность программ обеспечивает ее надежность, облегчает модификацию и ускоряет обработку
Структурное проектирование	Structured design	Метод проектирования, основанный на алгоритмической декомпозиции
Технология	Technology	Совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства, это совокупность технологических элементов (средств, устройств, методов, приемов, документов), используемых для обработки исходных материалов с целью получения конечной продукции
Технология программирования	Programming technology	Совокупность методов и средств, используемых в процессе разработки программных продуктов, представляет собой набор технологических инструкций
Унифицированный язык моделирования	Unified modeling language	Графический язык для визуализации, специфицирования, конструирования и документирования программных систем
Уровень абстракции	Level of abstraction	Относительное упорядочение абстракций по структурам классов, объектов, модулей или процессов
Эффективность	Efficiency	Отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов (различают эффективность по времени, по памяти, по оборудованию)

перечень ошибок

Класс ошибки	Категория ошибки
Ошибки вычислений	ошибки в вычислении номеров записей, индексов и в установке флажков
используемые уравнения неправильны /неточны;
неверный результат
смешение типов переменных в арифметических операторах
ошибки при вычислении и преобразовании интервалов времени
ошибочное использование соглашения о знаке
ошибки преобразования единиц измерения
ошибки в векторных операциях
результат вычислений не сходится;
ошибки квантования и округления.
Логические ошибки	физические характеристик решаемой задачи не учтены или неверно поняты
ошибка контроля установки начального значения или его изменения
ошибка при определении условий выхода из цикла (зацикливание программы; неверный цикл; не проверяется значение флажка или конкретного данного; неверно определен шаг итерации)
неправильный выход из цикла, незавершенный цикл
незавершенная обработка
опущена проверка условия
неправильная логика
нарушена последовательность логических условий (операций)
лишние логические действия
ошибки в определении состояния
неэффективная логика обработки (логика излишне сложна)
Ошибки ввода-вывода данных	нет вывода нужных данных
выводится недостаточное число элементов выходных данных
выводятся непредусмотренные элементы данных
не выдается сообщение об ошибке
вывод искажен или не соответствует спецификациям (выданное сообщение не соответствует проектной документации; искаженное или неточное сообщение об ошибке)
ошибочный формат входных или выходных данных (включая неверное расположение, неверный размер полей данных)
повторный или избыточный вывод
ошибки в отладочных выходных данных (в том числе слишком много отладочной информации)
ошибки в управлении печатью (ошибки в подсчете числа строк или форматировании станиц; ошибка управления печатающим устройством)
ошибки в указании формата данных при работе с внешней памятью (при вводе – выводе данных из файла)
выходных данных недостаточно для продолжения работы
не предусмотрен требуемый выход
Ошибки манипулирования данными	ошибки инициализации данных (входным данным присваиваются неверные начальные значения; достоверные данные используются неправильно; значение данного, индекса или флажка не установлено или установлено неверно)
ошибки размещения данных (данные записываются или считываются с неверных участков файла)
данные потеряны или не сохраняются
значение данного, индекса или флажка видоизменяется или обновляется неверно
число элементов данных определено неверно
ошибка при изменении входного числа элементов
ошибка при формировании цепочки данных
ошибки в операциях над данными в битах
ошибки преобразования целых чисел в форму с плавающей запятой (точкой) и обратно
переполнение или потеря значимости при вычислениях
поиск несуществующих данных
нарушение границ допустимых значений
ошибка в обработке длинных текстовых строк
ошибки сортировки
ошибки буферизации данных
Ошибки в операционных системах и вспомогательных программных средствах	операционная система не обеспечивает требуемую функцию
ошибка обращения к операционной системе (в вызывающе последовательности или в операциях инициализации)
ошибки по вине оборудования
программа использует вспомогательные программные средства неправильно

Ошибки компоновки	ошибка копмилирования
ошибки сегментации
неразрешенная команда
необъяснимый останов программы
Ошибки в межпрограммных интерфейсах	ошибки передачи данных (передается не тот объем данных: больший или меньший; передаются не те параметры или не в тех единицах измерения)
программная несовместимость (программа не загружается)
ошибки в вызывающей последовательности
несовместимость программ, приводящая к невозможности загрузки
ошибочное использование передаваемых ключей
использование программы не по назначению
Ошибки сопряжений с внешними устройствами хранения данных	нет проверки готовности устройства
ошибочный формат входных данных на внешнем носителе данных
программа не загружает файл с внешнего устройства.
Ошибки в пользовательских интерфейсах	ошибки в данных (неверно воспринимаются входные данные; входные данные считываются, но не используются; входные данные не вводятся и рассматриваются как недостоверные; воспринимаются и обрабатываются непредусмотренные данные; правильные входные данные обрабатываются неверно)
ошибочные проектные решения в части интерфейса
недостаточные возможности прерывания и рестарта
Ошибки сопряжения программы с базой данных	несовместимость программы с элементами данных
неправильное использование связей между элементами БД
нарушена целостность структуры БД
отсутствует координация процедур использования одних и тех же данных несколькими пользователями
Ошибки инициализации БД	ошибки в описании данных или запрашиваемых операциях
ошибки в номинальных, присваиваемых по умолчанию, максимально допустимых и в минимальных значениях
ошибки в физических константах и параметрах моделирования
ошибки в словарях данных
неверные сообщения об ошибках;
ошибки в нормативно-справочной информации
ошибки в битовых строках
не установлены начальные значения в данных.

Ошибки в определении глобальных данных (переменных и констант)	неверное расположение элементов данных (определены не в том блоке)
неправильное определение данных
ошибки в комментариях
Ошибки, лежащие в основе изменений по запросу пользователей	создание упрощенного и более удобного интерфейса пользователя
новые функции или расширение возможностей
изменения, касающиеся работы процессора, оперативной или внешней памяти
изменения, касающиеся операций ввода-вывода
введение средств защиты
предоставление новых возможностей оборудования или операционной системы
увеличение мощности
улучшение управления и обеспечение целостности БД
изменение внешнего программного интерфейса
Ошибки в документации	ошибки в описании возможностей программы
ошибки в описании режимов работы
ошибки в описании выполняемых функций
неверные сообщения об ошибках
расхождения между схемой алгоритма и программой
ошибки в описании входных и выходных форматов данных
документация неясна и неполна
ошибки в документации, касающейся контрольных примеров
ошибки, связанные с опечатками, редактированием и изменением внешнего вида
Нарушение технических требований	слишком большое время прогона программы
требуемая возможность пропущена при реализации или не реализована ко времени выпуска программы
Ошибки оператора	ошибки при прогоне теста
используется неверная база данных
используется неверная базовая конфигурация
используются не те файлы
Неопознанные ошибки

Учебное издание

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

#
#
07.06.20152.23 Mб14Учебник Кутафина.doc
#
#
#
#
#
#
#
#
#

Источник

GeekBrains продолжает серию статей о методологиях.

https://gbcdn.mrgcdn.ru/uploads/post/2011/og_image/a97147e5eb1efa005bf584db6775e914.png

Сегодня расскажем о RAD — Rapid Application Development, или быстрой разработке приложений.

Меньше слов, больше дела!

Идея RAD зародилась в 1980-х годах как альтернатива устаревающей методологии Waterfall, о которой мы уже писали. Каскадная модель программирования уже тогда воспринималась как перегруженная формальностями и недостаточно гибкая. Заказчик выдавал разработчику техническое задание и не видел результата до тех пор, пока программа не «сходила с конвейера» уже готовой, — и ожидания пользователя зачастую не оправдывались. Продукт мог оказаться слишком сложным, неудобным, а мог и устареть за время разработки.

В каскадной модели на ранних этапах работы проводится тщательное планирование, но это не помогает предусмотреть все риски и сложности. Поэтому проект дорожает, а время — уходит впустую.

В 1988 году американский инженер-программист Барри Боэм (Barry Boehm) опубликовал статью «Спиральная модель разработки и совершенствование программного обеспечения», в которой предложил создавать не цельную программу, а выпускать ряд прототипов, каждый из которых содержит дополнительную или расширенную функциональность по сравнению с предыдущим. Пользователь может изучить и попробовать в деле каждый прототип. Получая обратную связь, разработчик дорабатывает приложение, пока заказчик не получит готовый продукт, который полностью его устраивает.

Идея оказалась перспективной. Ее проработал специалист IBM Джеймс Мартин — в 1991 году вышла его книга «Быстрая разработка приложений» с изложением оригинальной методики применения RAD или Rapid Application Development. Спустя два года Джеймс Керр и Ричард Хантер написали книгу «Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше», где проанализировали подводные камни и возможности, которые они выявили при планировании и реализации успешного проекта RAD.

Эти книги заложили фундамент для практического применения RAD, и с тех пор эта методология остается в арсенале IT-разработчиков.

Нарисуйте мне программу

Плохие программы, не отвечающие потребностям пользователей, появляются потому, что заказчик и разработчик по-разному понимают задачу. Даже если будущий пользователь заранее составит подробное техническое задание и напишет спецификации, все равно остается шанс, что программист поймет их не так, как предполагалось. Пользователь и разработчик смотрят на программу с разных сторон: снаружи и изнутри. Заказчик зачастую хорошо понимает, что именно он хочет получить, но не очень ясно представляет, как этого достичь. Программист, напротив, отлично разбирается в устройстве программы, но не имеет четкого представления, что нужно пользователю.

RAD предлагает вести разработку так, чтобы заказчик мог увидеть практические результаты на самых ранних этапах — и скорректировать техническое задание, если это будет необходимо. Очередной цикл разработки начинается не раньше, чем пользователь оценил результаты предыдущего.

Изначально программист создает приложение в черновом варианте. Это могут быть наброски интерфейса и несколько пунктов меню. Если заказчика устраивает первый прототип, программа дорабатывается: добавляются новые элементы интерфейса, функциональность. С каждой итерацией приложение обрастает возможностями, и пользователь постоянно уточняет требования и задает вектор развития.

Методологию быстрой разработки RAD можно сравнить с работой художника. Сначала живописец делает эскиз. Потом создает черновой вариант картины. Затем он начинает прорабатывать элементы, добавляет детали, исправляет недочеты. Разумеется, не каждый заказчик способен по первому наброску представить себе, как будет выглядеть готовая картина, — возможно, он вообще не имеет понятия о перспективе или композиции. Но по крайней мере художнику не придется переписывать весь холст — ведь к завершению работы уже не окажется, что клиент перепутал натюрморт с пейзажем: «Нет-нет, я имел в виду сельский вид, а не корзину с фруктами!» Куда проще внести исправления в эскиз, чем в завершенное полотно.

RAD гарантирует, что в результате заказчик получит именно то, что ему нужно, — если в ходе разработки он последовательно одобрял каждый шаг, добавленные в проект детали и функциональные модули.

Быстро, качественно, дешево — выберите три из трех

Три кита, на которых покоится RAD, — это скорость разработки, качество программного кода и дешевизна. Да, это та самая методология, которая предлагает не выбрать два пункта из трех, а получить все сразу.

Почему быстро?

Методология RAD требует, чтобы работающие прототипы создавались максимально часто. Продолжительность одного производственного цикла — от выработки требований до демонстрации пользователю (то есть одной итерации) — от одного дня до трех недель.

Во многих случаях разумным вариантом будет разделить приложение на функциональные модули, каждый из которых можно создавать и тестировать отдельно. Модули разрабатываются параллельно разными командами, но по общей схеме: от простых прототипов к более сложным, с регулярным контролем со стороны заказчика. В конце работы или каждой итерации модули соединяют в цельное программное решение.

Полезны инструменты автоматизации разработки — они помогают переводить пожелания пользователя в формализованные требования и спецификации, на основании которых формируется модель программы.

Почему качественно?

Пользователь может определять, какую функциональность он хочет видеть реализованной в следующей итерации. Постоянное взаимодействие заказчика и разработчика гарантирует, что приложение будет развиваться в нужном направлении, интерфейс будет удобным, а функциональность востребованной. Такая схема избавляет программиста от лишней работы и исключает ситуации, когда часть программы приходится переделывать с нуля из-за неверно понятых вводных.

Почему дешево?

Деньги — странный предмет: вот они есть, а вот их нет. Бывает, что их не хватает, и приходится прерывать разработку, когда написана еще далеко не вся запланированная функциональность. Что получит заказчик в этом случае?

Если разработчик использует методологию Waterfall, то техническое задание и спецификации на программу он получает в самом начале работы. Какую из задач решать в первую очередь, а что оставить «на десерт», решает сам разработчик — при этом не всегда четко понимая, что для пользователя важно, а что не очень. В итоге заказчик, у которого внезапно закончились средства на проект, может получить программу, в которой реализованы второстепенные задачи, но отсутствует ключевая функциональность.

При Rapid Application Development пользователь сам решает, что ему требуется в первую очередь, и постоянно получает все более функциональные прототипы — то есть, фактически, работающие версии программы. Если финансирование внезапно иссякнет — пользователь не останется у разбитого корыта.

Разработка идет быстро, и заказчик получает программу существенно раньше — а это и экономия финансов.

Инструментарий RAD

Методология RAD еще с конца 1980-х была нацелена на использование новейших технологий ускорения разработки — и этот фокус на инструментах автоматизации по-прежнему актуален.

Средства автоматизации разработки программ (Computer-Aided Software Engineering), или CASE-инструменты — это программные продукты для проектирования приложений. Такая система позволяет быстро создать модель программы, а затем автоматически сгенерировать программный код. Получается прототип — запускаемый модуль, который можно продемонстрировать заказчику.

От одноклеточного к развитому: эволюция программы

Разработка приложения по методологии RAD проходит в несколько этапов.

Первый — анализ и планирование. Здесь определяются цели и задачи проекта — что и для чего будет делать приложение. Совместными усилиями заказчик и разработчик выявляют риски, устанавливают сроки и бюджет, определяют ключевые моменты разработки.

Затем начинается пользовательское проектирование. На этом этапе создается серия работающих прототипов программы. Каждый очередной прототип отличается от предыдущего дополненной функциональностью, изменениями дизайна и производительности. Процесс создания одного прототипа называется итерацией. RAD не накладывает жестких временных рамок на продолжительность одной итерации, но рекомендует, чтобы она была максимально быстрой.

В начале очередного цикла разработки заказчик и программист вместе формулируют требования, которым должна соответствовать очередная версия. Преимущество RAD в том, что не надо заранее продумывать каждую мелочь: сначала разрабатывается самая общая концепция, которая на следующих итерациях будет дополняться и уточняться.

Затем в дело вступают программисты. С помощью инструментов CASE они воплощают требования в виде модели, создавая очередной прототип. Его показывают пользователю и получают обратную связь. Уточняя пожелания и требования к программе, заказчик фактически руководит разработкой.

Прототип зачастую создается на скорую руку, только для проверки концепций. Это нормально: если пользователя устраивает новая функциональность и все работает как следует, в следующей итерации разработчик «отполирует» интерфейс и код. Перфекционизм может даже вредить — на очередном этапе любую доработку пользователь может посчитать неудачной. Если программист стремится сразу сделать все идеально, его усилия окажутся напрасными.

Как только заказчик дал обратную связь, цикл начинается заново. Вырабатывается план на следующую итерацию. Если пользователя что-то не устроило в прототипе, на новом витке цикла изменения откатывают назад и реализуют альтернативный вариант.

Если заказчик принял прототип — уточняем требования к функциональности, прорабатываем ее более детально, планируем новую. Обговариваем визуальные элементы и интерфейсы.

От прототипа к прототипу программный продукт приобретает вид завершенного приложения. Итерации выполняются, пока не будут реализованы последние требования.

Когда моделирование завершено, начинается конструирование: автоматически сгенерированный код дорабатывается и совершенствуется.

Финальный этап разработки — переключение. Готовый программный продукт тестируют, развертывают на пользовательских машинах, конвертируют информацию в новый формат или «заливают» в новые базы данных, подготавливают документацию и обучают операторов работе в системе.

Когда мы рады RAD’у, а когда не рады

У методологии RAD есть и преимущества, и недостатки, а также области применения, в которых она показывает себя лучше или хуже.

Эффективные варианты применения RAD

Если проект легко делится на независимые или слабосвязанные модули. Разработку в таком случае можно вести параллельно, несколькими командами, каждая из которых будет собирать прототип только одного модуля. В конце итерации или всей работы над программой модули объединяют в цельное приложение.
Если требования к программному обеспечению быстро меняются. RAD — отличный выбор, когда заказчик понимает, что программа нужна как можно скорее, но к концу работы над ней часть спецификаций наверняка изменится.
В условиях ограниченного бюджета. RAD гарантирует, что заказчик получит продукт, выполняющий поставленные задачи, даже если внезапно закончатся деньги.
Когда у пользователя нет ясного представления, как должен выглядеть и работать продукт. Поскольку программу создают небольшими итерациями, во время которых спецификации и требования постоянно уточняются, в итоге заказчик получает продукт, соответствующий его пожеланиям. Но лучше в общих чертах заранее сформулировать бизнес-цели и задачи для приложения.
Когда у вас есть коллектив хороших разработчиков и дизайнеров. Задача RAD — быстро создать качественный продукт. А это могут только профессионалы.
Если пользователь готов активно участвовать в проекте на протяжении всей работы — обсуждать нововведения и функциональность, тестировать прототип, давать обратную связь. Если у заказчика не хватает на это мотивации, стоит попробовать другие модели — например, Waterfall, где пользователь только формулирует ТЗ или спецификации.

Преимущества RAD — кратко

Разработка выполняется быстро и дешево.
RAD обеспечивает приемлемый для пользователя уровень качества.
Пользователь получает в итоге именно ту функциональность, которую хочет.
Пользователь может оперативно внести изменения в проект.
Функциональность, которая нужна заказчику «еще вчера», можно разработать в первую очередь, и использовать, даже если остальные части программы еще не готовы.

Недостатки RAD

RAD применима для больших команд.
RAD зависит от вовлеченности заказчика в работу. Если он не может принять участие в очередном обсуждении проекта, работа может приостановиться.

RAD уже не молодая методология — ей слегка за 30, — но она по-прежнему используется в разработке программного обеспечения и сдавать свои позиции не собирается. Ведь для методологии главное — не возраст, а эффективность.

Источник

В случае возникновения неисправности во время работы прибора на цифровой индикатор выводится соответствующее сообщение:

Неисправность Возможная причина Способ устранения На индикаторе при подключенном датчике отображаются Err.5 Неисправность датчика Замена датчика Обрыв или короткое замыкание линии связи «датчик-прибор» Проверить работоспособность датчика Неверный код типа датчика Установить код, соответствующий используемому датчику, в параметре in.t1 (in.t2) Неверно произведено подключение по двухпроводной схеме соединения прибора с датчиком Установить перемычку между клеммами 9–10 (для Н2 15–16) для первого канала и 13–14 (для Н2 – 11, 12) для второго канала Неверное подключение датчика к прибору Проверить по руководству эксплуатации схему подключения прибора и датчиков На индикаторе отображается ]]]] Измеренная величина или разность величин превышает значение 999,9 и не может быть отображена на четырехразрядном индикаторе с точностью 0,1 °С Установить значение 0 в параметре dPt1 (dPt2) На индикаторе отображается [[[[ Измеренная величина или разность величин меньше значения –199,9 и не может быть отображена на четырехразрядном индикаторе с точностью 0,1 °С Установить значение 0 в параметре dPt1 (dPt2) Значение измеряемой температуры на индикаторе не соответствует реальной Неверный код типа датчика Установить код, соответствующий используемому датчику, в параметре in.t1 (in.t2) Введено неверное значение параметров «сдвиг характеристики» и «наклон характеристики» Установить необходимые значения параметров SH1 (SH2), KU1 (KU2). Если коррекция не нужна, установить 0.0 и 1.000 соответственно. Используется двухпроводная схема соединения прибора с датчиком Воспользоваться рекомендациями к подключению датчика температуры типа термопреобразователь сопротивления (ТС) по двухпроводной схеме Действие электромагнитных помех Экранировать линию связи датчика с прибором, экран заземлить в одной точке На индикаторе при наличии токового сигнала отображаются нули Неверное подключение датчика к прибору Уточнить в руководстве по экслуатации схему подключения датчика Показания ЛУ1 (ЛУ2) дублируют показания ЛУ2 (ЛУ1) На вход обоих логических устройств подана одна регулируемая величина Задать параметру iLU1 значение Pu1, параметру iLU2 значение Pu2 Не работает выходное устройство Задан неверный режим работы логического устройства Задать в параметрах СtР1 (СtР2) или CtL1 (CtL2) требуемый режим работы (нагреватель, охладитель и т. д.) Значение гистерезиса компаратора непропорционально велико по сравнению с величиной уставки. При включении прибора температура оказывается в зоне Туст ± HYS Изменить значение (HYS1, HYS2) Задана задержка включения выходного устройства Задать параметру dOn1 (dOn2) значение 0. Выходное устройство не срабатывает при достижении заданных границ Введено минимальное время нахождения выходного устройства во включенном или/и выключенном состоянии Задать параметрам tOn1 и tOF1 значение 0 Задана задержка выключения выходного устройства Задать параметру doF1 (doF2) значение 0 На вход логического устройства подана разность входов. Задать параметру iLU1 значение Pu1, а параметру iLU2 – Pu2. Невозможно изменить
значения параметров SP1
и SP2 Выставлена защита от изменения
уставок 1) Задать параметру WtPt значение 0 (разрешено изменять все параметры) или 1 (можно изменять SP1 (SP2), но нельзя другие параметры)
2) В параметрах SL.L1 (SL.L2) и SL.H1 (SL.H2) установлено ограничение диапазона изменения значений уставок Нельзя изменить параметры любых групп Выставлена защита от изменения установок OAPT = 0
WTPT = 0

Источник