Программная инженерия-1

1. Программная инженерия

Software Engineering
Education Knowledge
(SEEK)

2. Цель курса:

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

3. Учебники

Книги:
В.В. Липаев. Программная инженерия. Методологические основы. Учебник. М.: ТЕИС, 2006.
К. Гецци, М. Джазайери, Д. Мандртоли. Основы инженерии программного обеспечения, 2-е издание, СПб.:
БХВ-Петербург, 2005.
Иан Соммервилл. Инженерия программного обеспечения, 6-е издание, М.: Издательский дом “Вильямс”,
2002.
Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. Управление программными проектами. Достижение оптимального
качества при минимуме затрат. М.: Издательский дом “Вильямс”, 2004.
Единая система программной документации. М.: ИПК Издательство стандартов, 2001.
Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — СПб.: Символ-Плюс,
1999. – 304 с.
Брауде Э.Д. Технология разработки программного обеспечения. — СПб.: Питер, 2004. — 656 с.
Кантор М. Управление программными проектами: Практическое руководство по разработке успешного
программного обеспечения. — М.: Вильямс, 2002. — 174 с.
Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ.,
СПб., Символ-Плюс, 1999.
«PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
Уолкер Ройс, «Адаптивный стиль управления программными проектами». Открытые системы. 2006. № 1.
Ершов А. П., «О человеческом и эстетическом факторе в программировании». Информатика и
образование. 1993. № 6.
Публикации в Интернет:
Software Engineering Conference (Russia) 2005, 2006, 2007 http://www.secr.ru/
Специалисты по методологии управления проектами разработки ПО - Алистер Кокберн и Мартин Фаулер
– http://alistair.cockburn.us/
– http://www.martinfowler.com/
Другие источники:
Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK) TECHNICAL
REPORT ISO/IEC TR 19759 IEEE First edition 2005-09-15
CMMI® for Development, Version 1.2, CMU/SEI-2006-TR-008 ESC-TR-2006-008

4. Введение в программную инженерию

5. Основные понятия

• Программная инженерия – это
применение систематического
подхода при разработке,
эксплуатации и поддержке
программного обеспечения.

6. Кратко даты

• Термин software ввел Джон Тьюкей (John
Tukey) в 1958 году, всемирно известный
статистик
• Термин software engineering впервые
появился в названии конференции НАТО в
1968 году
• С 1990 по 1995 велась работа над
стандартом ISO/IEC 12207
• В 2004 году создано «Руководство к своду
знаний по ПИ» SWEBOK

7.

• Программирование – процесс отображения
определенного М целей на М машинных команд,
интерпретация которых на К обеспечивает
достижение Ц
• Профессиональное программирование – получение
доходов при помощи П-я
• Профессиональный П Профессионал
• Программный продукт – С программ и
сопроводительной Д по настройке, использованию,
доработке
• Процесс разработки ПО – С процессов,
обеспечивающих создание и развитие ПО

8. Жизненный цикл программ

9.

• Модель процесса разработки ПО —
формализованное представление
процесса разработки ПО.
Согласно SWEBOK 2004, программная
инженерия включает в себя 10
основных и 7 дополнительных
областей знаний, на которых
базируются процессы разработки ПО.

10. ОСНОВНЫЕ

SOFTWARE REQUIREMENTS программные требования
SOFTWARE DESIGN дизайн (архитектура)
SOFTWARE CONSTRUCTION конструирование ПО
SOFTWARE TESTING тестирование
SOFTWARE MAINTENANCE эксплуатация (поддержка) ПО
SOFTWARE CONFIGURATION MANAGEMENT
конфигурационное управление
SOFTWARE ENGINEERING MANAGEMENT
управление в программной инженерии
SOFTWARE ENGINEERING PROCESS процессы ПИ
SOFTWARE ENGINEERING TOOLS AND
METHODS инструменты и методы
SOFTWARE QUALITY качество ПО

11. ДОПОЛНИТЕЛЬНЫЕ

COMPUTER ENGINEERING разработка компьютеров
COMPUTER SCIENCE информатика
MANAGEMENT общий менеджмент
MATHEMATICS математика
PROJECT MANAGEMENT управление проектами
QUALITY MANAGEMENT управление качеством
SYSTEMS ENGINEERING системное проектирование

12. ХАОС

Только 35 % проектов
завершились в срок, не
превысили запланированный
бюджет и реализовали все
требуемые функции и
возможности.
46 % проектов завершились с
опозданием, расходы
превысили запланированный
бюджет, требуемые функции
не были реализованы в
полном объеме. Среднее
превышение сроков
составило 120%, среднее
превышение затрат 100%,
обычно исключалось
значительное число функций.
19 % проектов полностью
провалились и были
аннулированы до
завершения.
• «Кто виноват?»
Объективная реальность
• «Что делать?»
Управлять людьми

13. ФАНТАЗЕРЫ

гуру программирования Ф.БРУКС, 1975 год:
«Программист, подобно поэту, работает
почти непосредственно с чистой
мыслью. Он строит свои замки в воздухе
и из воздуха, творя силой воображения.
Трудно найти другой материал,
используемый в творчестве, который
столь же гибок, прост для шлифовки
или переработки и доступен для
воплощения грандиозных замыслов».

14. ТВОРЧЕСТВО?

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

15. НЕ ИСКУССТВО. НЕ НАУКА.

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

16. АБСТРАКЦИИ

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

17. Обновление технологий

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

18. Программирование — не искусство и не наука — это РЕМЕСЛО. 

Программирование — не искусство
и не наука — это РЕМЕСЛО.
академик А.П.ЕРШОВ, в начале 70-х:
«Программист должен обладать способностью
первоклассного математика к абстракции и
логическому мышлению в сочетании с
эдисоновским талантом сооружать все, что
угодно, из нуля и единиц. Он должен сочетать
аккуратность бухгалтера с
проницательностью разведчика, фантазию
автора детективных романов с трезвой
практичностью экономиста»
Путь к мастерству в ремесле
лежит только через опыт.

19. Аналогия с киноиндустрией

• Для коллективного программистского творчества уместна
аналогия с созданием фильма. Количество провальных
проектов в этих областях ничуть не меньше, чем в
программировании - пятая часть кинофильмов «ложится на
полки» после первого показа.
Авторитет в управлении программными проектами У.Ройс:
«Менеджеры программных проектов смогут добиться
большего, если будут применять методы управления,
характерные для киноиндустрии».
• И еще одна аналогия программных проектов с кинематографом.
Наличие даже самых звездных актеров не обеспечивает успех
фильма. Только талантливый режиссер способен организовать
и вдохновить актеров на создание шедевра, открыть новые
звезды. А талантливых режиссеров, как, впрочем, и
талантливых менеджеров программных проектов, к сожалению,
не так много, как хотелось бы.

20. Эволюция подходов к управлению программными проектами

• «КАК ПОЛУЧИТСЯ». Разомкнутая система управления. Полное доверие
техническим лидерам. Представители бизнеса практически не участвует в проекте.
Планирование, если оно и есть, то неформальное и словесное. Время и бюджет, как
правило, не контролируются. Аналогия: баллистический полет без обратной связи. Можно,
но недалеко и неточно.
• «ВОДОПАД» или каскадная модель. Жесткое управление с обратной связью. Расчет
опорной траектории (план проекта), измерение отклонений, коррекция и возврат на
опорную траекторию. Лучше, но не эффективно.
• «Гибкое управление». Расчет опорной траектории, измерение отклонений, расчет
новой попадающей траектории и коррекция для выхода на нее. «Планы — ничто,
планирование — все» (Эйзенхауэр, Дуайт Дэвид)
• «Метод частых поставок». Самонаведение. Расчет опорной траектории,
измерение отклонений, уточнение цели, расчет новой попадающей траектории и коррекция
для выхода на нее.
Классические методы управления перестают работать в случаях, когда структура и
свойства управляемого объекта нам не известны и/или изменяются со временем.
Когда структура и свойства управляемого объекта нам не известны, необходимо
использовать АДАПТИВНОЕ управление, которое, дополнительно к прямым управляющим
воздействиям, направлено на изучение и изменение свойств управляемого объекта.
Продолжая аналогию с управлением летательными аппаратами — это расчет опорной
траектории, измерение отклонений, уточнение цели, уточнение объекта управления,
адаптация (необходимое изменение) объекта управления, расчет новой попадающей
траектории и коррекция для выхода на нее.

21. МОДЕЛИ ПРОЦЕССА РАЗРАБОТКИ ПО

Модели процессов
разработки ПО
принято
классифицировать
по «весу» —
количеству
формализованных
процессов и
детальности их
регламентации.

22. ГОСТы

• ГОСТ 19 «Единая система программной документации»
и
• ГОСТ 34 «Стандарты на разработку и сопровождение
автоматизированных систем»
ориентированы на последовательный подход к
разработке ПО. Разработка в соответствии с этими
стандартами проводится по этапам, каждый из которых
предполагает выполнение строго определенных работ, и
завершается выпуском достаточно большого числа
весьма формализованных и обширных документов.
Таким образом, строгое следование этим ГОСТам не
только приводит к водопадному подходу, но и требует
очень высокой степени формализованности разработки.
На основе этих стандартов разрабатываются
программные системы по госзаказам в России.

23. SW-CMM (Capability Maturity Model for Software)

5 уровней зрелости процесса разработки ПО.
• НАЧАЛЬНЫЙ — процесс разработки носит хаотический характер. Определены
лишь немногие из процессов, и успех проектов зависит от конкретных
исполнителей.
• ПОВТОРЯЕМЫЙ — установлены основные процессы управления проектами:
отслеживание затрат, сроков и функциональности. Упорядочены некоторые
процессы, необходимые для того, чтобы повторить предыдущие достижения на
аналогичных проектах.
• ОПРЕДЕЛЕННЫЙ — процессы разработки ПО и управления проектами
описаны и внедрены в единую систему процессов компании. Во всех проектах
используется стандартный для организации процесс разработки и поддержки
программного обеспечения, адаптированный под конкретный проект.
• УПРАВЛЯЕМЫЙ — собираются детальные количественные данные по
функционированию процессов разработки и качеству конечного продукта.
Анализируется значение и динамика этих данных.
• ОПТИМИЗИРУЕМЫЙ — постоянное улучшение процессов основывается на
количественных данных по процессам и на пробном внедрении новых идей и
технологий.

24. RUP (Rational Unified Process)

• разработан Филиппом Крачтеном (Philippe Kruchten),
Иваром Якобсоном (Ivar Jacobson) и другими
сотрудниками компании "Rational Software" в
качестве дополнения к языку моделирования UML.
Модель RUP описывает абстрактный общий процесс,
на основе которого организация или проектная
команда должна создать конкретный
специализированный процесс, ориентированный на
ее потребности. Именно эта черта RUP вызывает
основную критику — поскольку он может быть чем
угодно, его нельзя считать ничем определенным. В
результате такого общего построения RUP можно
использовать и как основу для самого что ни на есть
традиционного водопадного стиля разработки, так и
в качестве гибкого процесса.

25. MSF (Microsoft Solutions Framework)

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

26. PSP/TSP (Personal Software Process / Team Software Process)

определяет требования к компетенциям разработчика:
• учитывать время, затраченное на работу над проектом;
• учитывать найденные дефекты;
• классифицировать типы дефектов;
• оценивать размер задачи;
• осуществлять систематический подход к описанию результатов тестирования;
• планировать программные задачи;
• распределять их по времени и составлять график работы.
• выполнять индивидуальную проверку проекта и архитектуры;
• осуществлять индивидуальную проверку кода;
• выполнять регрессионное тестирование.
самоуправляемые команды численностью 3-20 разработчиков:
• установить собственные цели;
• составить свой процесс и планы;
• отслеживать работу;
• поддерживать мотивацию и максимальную производительность.
Последовательное применение модели PSP/TSP позволяет сделать нормой в
организации пятый уровень CMM.

27. AGILE

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

28. Выбор модели процесса

+
-
Тяжелые
Ср. квалификация исполнителей.
Большая специализация
исполнителей.
Ниже требования к стабильности
команды.
Отсутствуют ограничения по
объему и сложности
выполняемых проектов.
Требуют существенной
управленческой надстройки.
Более длительные стадии
анализа и проектирования.
Более формализованные
коммуникации.
Легкие
Меньше непроизводительных
расходов, связанных с
управлением проектом, рисками,
изменениями, конфигурациями.
Упрощенные стадии анализа и
проектирования, основной упор
на разработку
функциональности, совмещение
ролей. Неформальные
коммуникации.
Эффективность сильно зависит
от индивидуальных
способностей, требуют более
квалифицированной,
универсальной и стабильной
команды.
Объем и сложность
выполняемых проектов
ограничены.

29. НЕТ ЗАВИСИМОСТИ МЕЖДУ УСПЕХОМ И МОДЕЛЬЮ

Алистер Коуберн, один из авторов «Манифеста гибкой
разработки ПО» не обнаружил корреляции между
успехом или провалом проектов и моделями
процесса разработки, которые применялись в
проектах и сделал вывод о том, что эффективность
разработки ПО не зависит от модели процесса и:
– У каждого проекта должна быть своя модель процесса
разработки.
– У каждой модели — свое время.
Это означает, что не существует единственного
правильного процесса разработки ПО, в каждом
новом проекте процесс должен определяться каждый
раз заново, в зависимости от проекта, продукта и
персонала, в соответствие с «Законом 4-х П»

30. Закон 4П

31. Что надо делать для успеха программного проекта

1.Четко ставить цели.
2.Определять способ достижения целей.
3.Контролировать и управлять реализацией.
4.Анализировать угрозы и противодействовать им.
5.Создавать команду.

32. 1. СТАВИМ ЦЕЛИ

1.1. Концепция определяет ясные недвусмысленные цели.
1.2. Все члены команды считают концепцию реалистичной.
1.3. У проекта имеется обоснование экономической
эффективности.
1.4. Разработан прототип пользовательского интерфейса.
1.5. Разработана спецификация целевых функций
программного продукта.
1.6. С конечными пользователями продукта налажена
двухсторонняя связь

33. 2. Определяем способ достижения целей

2.1. Имеется детальный письменный план разработки продукта.
2.2. В список задач проекта включены «второстепенные» задачи
– управление конфигурациями,
– конвертация данных,
– интеграция с другими системами.
2.3. После каждой фазы проекта обновляется расписание и бюджет.
2.4. Архитектура и проектные решения документированы.
2.5. Имеется план обеспечения качества, определяющий тестирование и
рецензирование.
2.6. Определен план многоэтапной поставки продукта.
2.7. В плане учтены обучение, выходные, отпуска, больничные.
2.8. План проекта и расписание одобрен всеми участниками команды.

34. 3. Контролируем и управляем реализацией

3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании,
который лично заинтересован в успехе данного проекта.
3.2. У проекта есть менеджер, причем только один!
3.3. В плане проекта определены «бинарные» контрольные точки.
3.4. Все заинтересованные стороны могут получить необходимую информацию
о ходе проекта.
3.5. Между руководством и разработчиками установлены доверительные
отношения.
3.6. Установлена процедура управления изменениями в проекте.
3.7. Определены лица, ответственные за решение о принятии изменений в
проекте.
3.8. План, расписание и статусная информация по проекту доступна каждому
участнику.
3.9. Код системы проходит автоматическое рецензирование.
3.10. Применяется система управления дефектами.

35. 4. Анализируем угрозы

4.1. Имеется список рисков проекта.
Осуществляется его регулярный анализ и
обновление.
4.2. Руководитель проекта отслеживает
возникновение новых рисков.
4.3. Для каждого подрядчика определено лицо,
ответственное за работу с ним.

36. 5. Работаем над созданием команды

5.1. Опыт команды достаточен для выполнения
проекта.
5.2. У команды достаточная компетенция в
прикладной области.
5.3. В проекте имеется технический лидер.
5.4. Численность персонала достаточна.
5.5. У команды имеется достаточная сплоченность.
5.6. Все участники привержены проекту.

37. Этот чек-лист перечисляет, ЧТО надо делать для успеха программного проекта, но НЕ ДАЕТ ответ на вопрос КАК это следует делать.

Этот чек-лист перечисляет, ЧТО надо делать
для успеха программного проекта, но НЕ ДАЕТ
ответ на вопрос КАК это следует делать.
Оценка и интерпретация теста
• Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:
• 0 — даже не слышали об этом;
• 1 — слышали, но пока не применяем;
• 2 — применяется частично;
• 3 — применяется в полной мере.
Поправочные коэффициенты:
• для малых проектов (до 5 человек) — 1.5;
• для средних (от 5 до 20 человек) — 1.25.
Результат:
• <40 — завершение проекта сомнительно.
• 40-59 — средний результат. В ходе проекта следует ожидать
серьезные проблемы.
• 60-79 — хороший результат. Проект, скорее всего, будет успешным.
• 80-89 — отличный результат. Вероятность успеха высока.
• >90 — великолепный результат. 100% шансов на успех.

38. FAQ об инженерии ПО

Вопрос
Что такое программное обеспечение (ПО)?
Ответ
Это компьютерные программы и соответствующая документация. Программные продукты
разрабатываются или по частному заказу, или для продажи на рынке программных продуктов
Что такое инженерия программного
обеспечения?
В чем различие между инженерией
программного обеспечения и компьютерной
наукой?
Это инженерная дисциплина, охватывающая все аспекты разработки программного
обеспечения
Компьютерная наука – это теоретическая дисциплина, охватывающая все стороны
вычислительных систем, включая аппаратные средства и программное обеспечение;
инженерия программного обеспечения – практическая дисциплина создания и
сопровождения программных систем
В чем различие между инженерией
Системотехника охватывает все аспекты разработки вычислительных систем (включая
программного обеспечения и системотехникой? создание аппаратных средств и ПО) и соответствующие технологические процессы.
Технологии инженерии программного обеспечения являются частью этих процессов
Что такое технологический процесс создания
ПО?
Что такое модель технологического процесса
создания ПО?
Какова структура затрат на создание ПО?
Это совокупность процессов, ведущих к созданию или развитию программного обеспечения
Что такое методы инженерии программного
обеспечения?
Это структурные решения, предназначенные для разработки ПО и включающие системные
модели, формализованные нотацию и правила проектирования, а также способы управления
процессом создания ПО
Что такое CASE (Computer-Aided Software
Engineering – автоматизированное
проектирование и создание ПО)?
Это программные системы, предназначенные для автоматизации процесса создания ПО.
CASE-средства часто используются в качестве основы методов инженерии программного
обеспечения
Каковы признаки качественного ПО?
Программные продукты должны удовлетворять требованиям функциональности и
эффективности (с точки зрения пользователя), а также быть надежными, удобными в
эксплуатации и иметь возможности для модернизации
Формализованное упрощенное представление технологического процесса создания ПО
Примерно 60% от общих затрат на создание ПО занимают затраты непосредственно на
разработку ПО и 40% – на его тестирование и отладку. Для программных продуктов,
разрабатываемых по заказу, стоимость тестирования и отладки часто превышает стоимость
разработки продукта
Какие основные проблемы стоят перед
Проблема наследования ранее созданного ПО, проблема все возрастающей разнородности
специалистами по программному обеспечению? программных систем и проблема, порожденная требованием уменьшения времени на
создание ПО

39. Компоненты методов инженерии ПО

Компонент
Описание
модели
системы
Описание
Пример
Описания моделей создаваемых Модели объектов, модели
систем и нотация, используемая для потоков данных, модели
разработки этих моделей
конечных автоматов и т.п.
Правила
Правила и ограничения, которые
необходимо выполнять при
разработке моделей систем
Каждый элемент модели
должен иметь уникальное
имя
Рекомендации Эвристические советы и
Любой объект в модели не
рекомендации, отражающие
должен иметь более семи
практический опыт применения
подчиненных ему объектов
данного метода
Руководство
по
Описание работ, которые
Атрибуты любого объекта
применению необходимо выполнить для
должны быть
метода
построения модели системы, а
документированы, прежде
также рекомендации по организации чем будут определены
этих работ
операции, связанные с этим
объектом

40. Характеристики качественного ПО

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

41. Проблемы, стоящие перед специалистами по ПО

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

42. Профессиональные и этические требования к специалистам по ПО

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

43. Кодекс этики, разработанный ACM/IEEE (©IEEE/ACM 1999)

1.
2.
3.
4.
5.
6.
7.
8.
Общественные интересы – деятельность специалистов по программному
обеспечению должна проистекать в соответствии с общественными интересами и
запросами.
Клиенты и работодатели – деятельность специалистов по программному
обеспечению должна быть направлена на удовлетворение запросов клиентов и
работодателей в соответствии с общественными интересами.
Производство – специалист по программному обеспечению должен
гарантировать, что произведенные или модифицированные им программные
продукты соответствуют самым высоким, какие только возможны,
профессиональным стандартам.
Профессиональные суждения – специалист по программному обеспечению
должен поддерживать честность, непредвзятость и независимость своих
профессиональных суждений и оценок.
Управление – действия руководителей программных проектов должны
подчиняться высоким этическим нормам при их руководстве разработкой и
сопровождением программного обеспечения.
Профессия – специалист по программному обеспечению должен поддерживать на
высоком уровне репутацию своей профессии в соответствии с общественными
интересами.
Коллегиальность – специалист по программному обеспечению должен
поддерживать коллег и быть достойным членом своего коллектива.
Личность – специалист по программному обеспечению должен постоянно учиться,
чтобы соответствовать уровню своей профессии, а также должен
руководствоваться высокими этическими нормами в повседневной практической
профессиональной деятельности.

44. Управление проектами. Определения и концепции

45. Проект — основа инноваций

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