технологии программирования к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL

Системный подход в технологии программирования

Качество программного обеспечения

3.7.1. Подходы к качеству программного обеспечения
3.7.2. Характеристики качества программного обеспечения
3.7.3. Оценка качества процесса разработки

3.7.3.1. Модель зрелости процесса разработки программного обеспечения
3.7.3.2. Определение возможностей и улучшение процесса создания программного обеспечения

3.7.4. "Достаточно хорошее" программное обеспечение
3.7.5. Стандартизация информационных технологий

Мы должны отыскать себе благородного мужа, которого мы имели бы всегда
перед глазами, чтобы жить, точно он всегда смотрит на нас,
и поступать, точно он видит наши поступки.
Эпикур

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

3.7.1. Подходы к качеству программного обеспечения

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

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

В табл. 3.2 приведены примеры каждого из четырех подходов:

ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик;
"усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;
ISO 9000 [ISO 9000 1992] - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" [ISO 9001 1992];
методы усовершенствования процесса разработки программного обеспечения предлагают некоторую шкалу уровней и требования соответствия, согласно которым можно определить место компьютерной компании на этой шкале. Наиболее известны и популярны два метода:

модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);
определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).

Таблица 3.2. Подходы к качеству

Объект качества	Соответствие	Усовершенствование
Продукт	ISO 9126	"Усовершенствование практики"
Процесс	ISO 9000, процесс обеспечения качества	CMM, SPICE, ...

Два важнейших утверждения лежат в основе достижения качества.

Качество начинается с удовлетворения потребностей разработчиков.
Качество доказывается удовлетворением потребностей пользователей.

Подходы к достижению качества таковы:

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

3.7.2. Характеристики качества программного обеспечения

В настоящее время не существует общепринятых критериев качества программного обеспечения.
Стандарт ISO 9000-3, п. 6.4.1

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

Современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Перечислим ряд таких характеристик [Жоголев 1996].

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

Две наиболее интересные характеристики рассмотрим подробнее.

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

Существуют следующие подходы по обеспечению надежности:

предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.

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

Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик. *

Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.
Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.
Оценка модульного разбиения программы. Такая оценка должна состоять из множества критериев. Например, сложность модуля оценивается совокупностью сложности определяемых в нем процедур и сложности связей модуля с другими модулями по импорту и экспорту определяемых сущностей.

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

3.7.3. Оценка качества процесса разработки

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

В начале данного раздела мы отметили, что существует два подхода, которые могут применяться для оценки качества программного продукта.

Оценить качество конечного продукта.
Оценить качество процесса разработки.

Оценить качество конечного продукта можно тестированием и эксплуатацией. На это должно быть отведено время после завершения основной работы над программой. А вот второй подход должен стать частью долговременной стратегии компании.

3.7.3.1. Модель зрелости процесса разработки программного обеспечения

В модели определено пять уровней зрелости организации (http://www.sei.cmu.edu/cmm).

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

3.7.3.2. Определение возможностей и улучшение процесса создания программного обеспечения

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

Уровень 0. Процесс не выполняется.
Уровень 1. Выполняемый процесс.
Уровень 2. Управляемый процесс.
Уровень 3. Установленный процесс.
Уровень 4. Предсказуемый процесс.
Уровень 5. Оптимизирующий процесс.

Во время оценки и улучшения качества процессов выполняются задачи [Терехов, Туньон 1999], описанные ниже.

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

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

3.7.4. "Достаточно хорошее" программное обеспечение

Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии
новой программы компании Microsoft произошло землетрясение.
Пользователи с ужасом ждут объявления о выходе финальной версии продукта.
Анекдот по мотивам землетрясения и выступления Б. Гейтса 23-го февраля 2001 г.

Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.

Оказывается, что даже "достаточно хорошее" программное обеспечение создать сложно. Приведем часть из совокупности причин, дающих этому объяснение [Йордон 2001].

Часто качество стремятся определить только в терминах дефектов (ошибок). С точки зрения пользователя не менее важны такие стороны, как готовность к определенной дате.
Предполагается, что малое количество ошибок равносильно лучшему качеству, и пользователь предпочитает именно такое качество. Однако иногда пользователь готов идти на компромиссы и примириться с некоторыми ошибками в обмен на более скорое выполнение работы.
Игнорирование таких факторов, как моральное состояние команды разработчиков и адекватные условия для работы.

Джеймс Бах (James Bach) [Bach 1995] указывает следующие необходимые условия для создания "достаточно хорошего" программного обеспечения:

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

К сожалению, "достаточно хорошее" программное обеспечение редко бывает действительно достаточно хорошим. Никлаус Вирт отмечает, что это "следствие грустного проявления духа нашего времени, в котором исчезает личная гордость за свою работу". По его мнению, "нельзя ожидать качественно выполненной работы, если не отдавать ей себя полностью, если нет личного удовлетворения, более того - удовольствия от нее".

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

3.7.5. Стандартизация информационных технологий

Стандарт - общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль - набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи [Козлов 1999].

Стандарты можно классифицировать следующим образом:

по типу установления требований:

устанавливающие требования к объекту;
устанавливающие требования к процессу;

по масштабу:

международные;
государственные;
отраслевые;
предприятий;

по степени юридического оформления:

принятые юридически;
действующие фактически.

Процесс стандартизации информационных технологий поддерживают три основные группы организаций (http://www.citforum.ru/programming/prg96 /sukhomlin.shtml).

Международные организации, входящие в структуру ООН.

International Organization for Standardization (ISO) - международная организация по стандартизации.

Об ISO
В 1947 году представители 25 стран решили создать организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). Несоответствие полного названия и аббревиатуры объясняется тем, что "ISO" - это греческий префикс, означающий "равный".

International Electrotechnical Commision (IEC) - международная электротехническая комиссия.
International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.

Промышленные профессиональные или административные организации.

Institute of Electrical and Electronic Engineers (IEEE) - институт инженеров по электротехнике и электронике.
Internet Activity Board (IAB) - совет управления деятельностью Интернета.

Промышленные консорциумы.

Object Management Group (OMG) - группа управления объектами.
Х/Open - консорциум, организованный группой поставщиков компьютерной техники.
Open Software Foundation (OSF) - фонд открытого программного обеспечения.

В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий.

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

ЛИТЕРАТУРА

Если вы прочли эту книгу и поняли ее - обратитесь по адресу ... - мы выплатим вам
стоимость этой книги и найдем высокооплачиваемую работу не менее ... марок в месяц.
(Надпись на карточке, приклеенной в конце книги "Jetzt lerne ich Perl")

1. Агафонов 1984 - Агафонов В. Н. Языки и средства спецификации программ (обзор). // Требования и спецификации в разработке программ. - М.: Мир, 1984, с. 285-344.

2. Ахтырченко, Леонтьев 2001 - Ахтырченко К. В., Леонтьев В. В. Моделирование программной архитектуры // Вычислительные методы и программирование. 2001. Т. 2, с. 33-48.

3. Баранов 1998 - Баранов С. Н. Управление программным проектом. Лекции по спецкурсу "Технология программирования". - СПб: Санкт-Петербургский государственный электротехнический университет, рукопись, 1998.

4. Бек 2000 - Кент Бек. Экстремальное программирование. // Открытые системы, № 1-2, 2000.

5. Богатырев 2001 - Руслан Богатырев. Linux: истоки новой философии программирования. // Мир ПК, № 1, 2001.

6. Брукс 1999 - Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - СПб.: Символ-Плюс, 1999.

7. Буч 1998 - Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд. - М.: Бином, СПб.: Невский диалект, 1998.

8. Буч, Рамбо, Джекобсон 2000 - Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМК, 1998.

9. Вендров 2000 - Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000.

10. Гамма, Хелм, Джонсон, Влиссидес 2001 - Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного программирования. Паттерны проектирования. - СПб.: Питер, 2001.

11. Гейтс 2001 - Гейтс Б. Бизнес со скоростью мысли.- М.: ЭКСМО-Пресс, 2001.

12. Гласе, Нуазо 1983 - Гласе Р., Нуазо Р. Сопровождение программного обеспечения. - М.: Мир, 1983.

13. Грановская, Березная 1991 - Грановская Р. М. Березная И. Я. Интуиция и искусственный интеллект. - Л.: Изд-во ЛГУ. 1991.

14. Деметрович, Кнут, Радо 1989 - Деметрович Я., Кнут Е., Радо П. Автоматизированные методы спецификации. - М.: Мир, 1989.

15. Жоголев 1996- Жоголев Е. А. Лекции по технологии программирования. - М.: МГУ, факультет ВМиК, рукопись, 1996.

16. Йордон 2001 - Эдвард Йордон. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. - М.: ЛОРИ, 2001.

17. Калянов 1996- Калянов Г. Н. CASE структурный системный анализ (автоматизация и применение). - М.: ЛОРИ, 1996.

18. Канер, Фолк, Нгуен 2000- Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. - К.: ДиаСофт, 2000.

19. Керниган, Пайк 2001 - Керниган Брайан В., Пайк Роб. Практика программирования. - СПб.: Невский диалект, 2001.

20. Кинг 1991 - Кинг Д. Создание эффективного программного обеспечения. - М.: Мир, 1991.

21. Кнут 2000 - Дональд Кнут. Искусство программирования, том 1. Основные алгоритмы (3-е изд.). - М.: Издательский дом "Вильяме", 2000.

22. Козлов 1999 - Козлов В. А. Открытые информационные системы. - М.: Финансы и статистика, 1999.

23. Косовский, Хитрое 1997 - Косовский Н. К., Хитров Д. В. Агрегация инноваций для повышения результативности систем // Первый российский философский конгресс. Санкт-Петербург, 1997. Том V, с. 122-124.

24. Кулаичев 1999 - Кулаичев А. П. Методы и средства анализа данных в среде Windows. - М.: Информатика и компьютеры. 1999.

25. Липаев 1986 - Липаев В. В. Тестирование программ. - М.: Радио и связь, 1986.

26. Майерс 1980 - Майерс Г. Надежность программного обеспечения. - М.: Мир, 1980.

27. Пашкус, Мисько 1991 - Пашкус Ю. В. Мисько О. Н. Введение в бизнес. - Л.: "Северо-Запад", 1991.

28. Пойа 1957 - Д. Пойа. Математика и правдоподобные рассуждения. - М.: Изд-во иностранной литературы, 1957.

29. Поттосин 1997 - Поттосин И. В. "Хорошая программа": попытка точного определения понятия. // Программирование, 1997, № 2, с. 3-17.

30. Психология 2000 - Психология менеджмента: учебник. - СПб.: Изд-во Санкт-Петербургского университета, 2000.

31. Романовский 1999- Романовский И. В. Дискретный анализ. - СПб.: Невский диалект, 1999.

32. Тассел 1985 - Д. ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985.

33. Терехов, Туньон 1999 - Терехов А. А., Туньон В. Современные модели качества программного обеспечения. // BYTE/Россия. № 12, 1999.

34. Турский 1981 - Турский В. Методология программирования. - М.: Мир, 1981.

35. Фаулер, Скотт 1999 - Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. - М.: Мир, 1999.

36. Физики 1968 - Физики продолжают шутить. - М.: Мир, 1968.

37. Филлит, Гарсиа-Диас 1984- Филлипс Д., Гарсиа-Диас А. Методы анализа сетей. - М.: Мир, 1984.

38. Фоке 1985 - Дж. Фоке. Программное обеспечение и его разработка.- М.: Мир, 1985.

39. Ходяченко 1999 - Ходяченко В. Б. Маркетинг: учебное пособие. - СПб.: Изд-во Санкт-Петербургского университета, 1999.

40. Холстед 1981 - Холстед М. X. Начала науки о программах. - М.: Финансы и статистика, 1981.

41. Цейтин 1990 - Цейтин Г. С. На пути к сборочному программированию// Программирование, 1990, № 1, с. 78-92.

42. Шевчук, Харахоркина, Журавлев, Армен 1998 - Шевчук О. Б., Харахоркина А. А., Журавлев Б. С., Армен В. А. Защищайтесь, сударь! Руководство по созданию и защите диссертаций. - СПб.: Политехника, 1998.

43. Шлеер, Меллор 1993 - Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. - Киев: Диалектика, 1993.

44. Abrial 1996- Abrial J.-R. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996.

45. Bach 1995 - James Bach. The Challenge of "Good Enough" Software. // American Programmer, October 1995.

46. Boehm 1981 - Boehm B. W. Software Engineering Economics. Prentice Hall, 1981.

47. Conger 1994 - Conger, Sue A. The New Software Engenering. Wadsworth Publishing Company, 1994.

48. ISO/IEC 12207:1995- ISO/IEC 12207:1995 Information Technology- Software Life Cycle Processes.

49. ISO 9000 1992 - ISO 9000 International Standards for quality Management, Geneva, Switzerland, International Organization for Standartization, 1992.

50. ISO 90011992 - Quality management and quality assurance standard - Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software.

51. Linger 1994 - Richard C. Linger. Cleanroom process model.// IEEE Software, March 1994, pp. 50-58.

52. Robillard, Robillard 2000 - Pierre N. Robillard, Martin P. Robillard. Types of collaborative work in software engineering. // The Journal of Systems and Software 53, 2000, pp. 219-224.

53. Safonov 1996 - Safonov V. O. Compiler Reengineering Methodology and its Application to SUN Pascal Compiler. // Perspectives of System Informatics. Andrej Ershov Second International Memorial Conference. Akademgorodok, Novosibirsk Russia, June 25-28, 1996, pp. 292-294.

54. Sommerville 1992 - Ian Sommerville. Software Engineering. Addison-Wesley Publishing Company, 1992.

55. Shaw, Garlan 1996 - M. Shaw, D. Garlan. Software Architecture: Perspectives on an Emergine Discipline. Prentice Hall, 1996.

56. Thomsett 1990 - Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution. American Programmer, July-August 1990.

57. Vliet 2000 - Vliet H. V. Software Engineering: Principles and Practice. Join Wiley and Sons, 2000.

58. Walston, Felix 1977- Walston C. E., Felix C. P. A Method of Programming Measurement and Estimation. // IBM Systems Journal, Vol. 16, No. 1, 1977, pp. 54-73.

технологии программирования к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL

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

НОВОСТИ ФОРУМА

Рыцари теории эфира