Содержание
- 2. Контрольные точки работы 1 модуль. Презентация должна содержать в себе постановку задачи (1 балл), обоснование актуальности
- 3. Рекомендуемая литература Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем: Учебное пособие. – 3-е
- 4. Лекция 1. Программное обеспечение компьютерных систем ПО и его классификации ПО – совокупность программ, выполняемых вычислительной
- 5. Сфера применения ПО ПО современных компьютеров включает миллионы программ – от игровых до научных. ПО по
- 6. Классификация ПО по способу распространения Коммерческое ПО; Бесплатные программы; Условно-бесплатные (их можно получить и опробовать бесплатно,
- 7. Пакеты прикладных программ ППП – комплект программ, предназначенных для решения задач в определенной области Выделяет следующие
- 8. Программные средства и продукты Программные средства – математические средства, с помощью которых решаются задачи автоматизированного получения,
- 9. При индивидуальной разработке фирма-разработчик создает оригинальный программный продукт, учитывающий специфику обработки данных для конкретного заказчика. При
- 10. Рынок программных продуктов На рынке ПП действуют: Поставщики ПП; Потребители ПП; Посредники. В условиях существования рынка
- 11. Маркетинг ПП массового распространения продаются по ценам, которые учитывают конъюнктуру рынка (наличие и цены программ-конкурентов). Большое
- 12. Приобретение программного продукта – это покупка лицензии – права на его использование. Условия использования любого программного
- 13. Лицензия ПО на компьютере находится в «пользовании», когда оно помещено в постоянную память (жесткий диск или
- 14. Приобретение лицензии Существует несколько вариантов приобретения лицензии. Наиболее известный и распространенный путь – покупка коробки с
- 15. Лекция 2 Разработка ПС Стадии разработки ПО, регламентированные ГОСТ В РФ ЖЦ разработки ПО установлен стандартом
- 16. Техническое задание На стадии ТЗ выполняются следующие работы, входящие в состав соответствующих этапов. Обоснование необходимости разработки
- 17. Эскизный проект Результатом выполнения данной стадии является полное описание архитектуры ПО. Как правило, это описание делается
- 18. Технический проект Содержанием работ по этой стадии является проектирование структуры ПО. Результатом – реализующий заданный и
- 19. Рабочий проект Содержанием работ на этой стадии является описание ПО на выбранном проблемно-ориентированном языке (кодирование), разработка,
- 20. Качество ПО Качество ПО – способность ПО подтвердить свою спецификацию при условии, что спецификация ориентирована на
- 21. Рекомендуется следующая общая схема процессов оценки характеристик качества программ: Функциональная пригодность – наиболее неопределенная характеристика программного
- 22. Оценка защищенности программных средств включает определение полноты использования доступных методов и средств защиты программного средства от
- 23. Оценка практичности программных средств проводится экспертами и включает определение понятности, простоты использования, изучаемости и привлекательности программного
- 24. Надежность ПО Надежность ПО – способность ПП безотказно выполнять определенные функции при заданных условиях с большой
- 25. Понятие корректной программы рассматривается статически вне времени функционирования. Неправильность программы определяется вероятностью совмещения следующих событий: Попадания
- 26. Надежная программа должна обеспечивать низкую вероятность отказа в процессе функционирования. Количество ошибок в программе не имеет
- 27. Лекция 3 Жизненный цикл ПО Жизненный цикл (ЖЦ) программной системы – это последовательность этапов, через которую
- 28. Варианты жизненного цикла программ
- 29. Варианты жизненного цикла программ Также различают различные виды жизненных циклов и проектирования по виду сборки готового
- 30. При проектировании сверху вниз проводится общий анализ системы: определяются входные и выходные данные, требования к ним.
- 31. Распределение работ Существует эмпирический закон, который гласит, что в процессе создания ПО 30% времени тратится на
- 32. Анализ Этап анализа требований посвящен работе с заказчиком. На данном этапе заказчик предъявляет требования к создаваемой
- 33. Анализ. Разработка требований и внешнее проектирование ПО 1. Общая схема создания ПО Процесс создания программ можно
- 34. Постановка задачи это точная формулировка решения задачи на компьютере с описанием входной и выходной информации. К
- 35. Алгоритм Система точно сформулированных правил, определяющая процесс преобразования допустимых исходных данных в желаемый результат за конечное
- 36. Программирование Программа – реализованной алгоритм на языке программирования. Наиболее часты программисты делятся на системных и прикладных.
- 37. 2. Разработка требований к ПО Наиболее оптимальной является совместная работа проектировщиков и пользователей по выработке требований.
- 38. 3. Цели разработки ПО Цели разработки обычно включают следующую информацию: Краткое описание ПО Определение круга пользователей
- 39. 4. Разработка внешних спецификаций проекта Внешнее проектирование – это процесс описания планируемого поведения разрабатываемого ПО с
- 40. Предварительный внешний проект содержит описание основных компонентов и внешних функций, составляющих отдельные компоненты проекта. Неопределенным остается
- 41. Лекция 5 Проектирование и разработка Пользовательский интерфейс является своеобразным коммуникационным каналом, по которому осуществляется взаимодействие пользователя
- 42. Общие принципы проектирования пользовательских интерфейсов Программа должна помогать выполнить задачу, а не становиться этой задачей. При
- 43. Графический интерфейс пользователя Графический интерфейс пользователя (GUI) является обязательным компонентом большинства современных программных продуктов, ориентированных на
- 44. Формы Формы – это строительные блоки интерфейса пользователя. Формы делятся на два вида: формы ввода и
- 45. Диалоговый режим Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя, работают в диалоговом режиме
- 46. Системы, поддерживающие диалоговые процессы, классифицируются на: Системы с жестким сценарием диалога – стандартизированное представление информации обмена;
- 47. Диалоговые системы с жестким сценарием диалога Наиболее просты для реализации и распространены диалоговые системы с жестким
- 48. Разработка Собственно разработка ПО заключается в детальном проектировании отдельных работ и их реализации. Обычно считается, что
- 49. Также менеджеру следует помнить, что увеличение длительности рабочей недели не всегда положительно сказывается на производительности. Йордон
- 50. Тестирование ПО Роль этапа тестирования зачастую незаслуженно принижается. Однако ошибки в программном коде – явление не
- 51. Виды тестирования Существует несколько видов тестирования. Начальное тестирование проводится непосредственно разработчиками для того, чтобы убедиться, что
- 52. Функциональное тестирование преследует своей целью проверку корректности работы приложения. В таком виде тестирования основными задачами является
- 53. Развертывание ПО Развертывание приобретает высокую актуальность для больших систем. В простейшем случае программа сдается заказчику на
- 54. Сопровождение ПО Сопровождение ПО также следует предусмотреть еще на этапе проектирования, так как его стоимость может
- 55. Лекция Документация ПО Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки
- 56. Перечень документов ЕСПД ГОСТ 19.001-77 ЕСПД. Общие положения. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.
- 57. ГОСТ 19.402-78 ЕСПД. Описание программы. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению. ГОСТ
- 58. Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также относящихся к документированию ПО и
- 59. ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения для их представления ГОСТ Р
- 60. Стандарт ISO 9000 Это целая группа стандартов, предъявляющая требования к процессу разработки, выпуска и поддержки продуктов
- 61. ISO 9004:2009 предоставляет методическую помощь по более широкому спектру целей системы менеджмента качества, нежели это делает
- 62. Система качества Функционирование и применение системы качества на предприятии - разработчике ПС проверяется путем аудита наличия
- 63. Облегченные методики разработки ПО Классические методики разработки ПО рассчитаны на то, что известно, какой объем работы
- 64. Спиральная модель разработки Спиральная модель разработки ПО построена следующим образом. На начальных этапах разработки формируются основные
- 65. На каждой итерации рекомендуется придерживаться следующих шагов. Формирование видения проблемы. В ходе встречи с заказчиком выясняется,
- 66. Экстремальное программирование Экстремальное программирование работает только в случае, если вы имеете небольшую команду профессионалов (не больше
- 67. Принципы экстремального программирования 1. Простота проектирования – сдаваемая система будет наиболее простой системой, отвечающей требованиям заказчика
- 68. Методология SCRUM Методология SCRUM основывается на проведении недлинных (порядка 30 рабочих дней) этапов, называемых спринтами. В
- 69. В ходе выполнения спринта проводятся ежедневные собрания. Основной задачей таких собраний является ответ на три основные
- 70. Персональный процесс разработки До сих пор мы рассматривали процесс разработки с точки зрения менеджера проекта. Однако
- 71. Этапы PSP Этап PSP 0. На данном этапе программист учится составлять общий план проекта, оценивать время
- 72. Этапы PSP Этап PSP 1.1. На данном этапе программист, на основе полученных количественных данных, учится оценивать
- 73. Этапы PSP Этап PSP 2. Здесь программист учится качественно проектировать программу в целом. На предыдущих этапах
- 74. Уровни зрелости компании Для оценки эффективности производства программными продуктами используют уровни зрелости компании. В соответствии с
- 75. 1 Этап Практически все компании, начинающие свою деятельность находятся на первом уровне зрелости, зачастую называемом хаотическим.
- 76. 2 Этап Повторяющиеся процессы позволяют наладить управление процессом разработки, сделать его более предсказуемым. Кризисы в таких
- 77. 3,4,5 этапы Переход к определенным процессам позволяет осуществлять разработку твердо представляя себе порядок, объем и сложность
- 78. Лекция. Инструментальные средства разработки ПО. История Несмотря на развитие инструментальных средств до середины 70-х годов не
- 79. История. 1 этап На первом этапе основные затраты были связаны с кодированием программ, реализующих известные алгоритмы
- 80. История. 2 этап Второй этап развития программных средств характеризуется увеличением размеров программ и увеличением затрат на
- 81. История. 3 этап Третий этап бы связан с обобщением и интеграцией найденных решений в больших языков
- 82. Инструментальные средства разработки ПО В процессе разработки программного обеспечения используется большое количество самого разностороннего ПО: Необходимые
- 83. Текстовые редакторы Не имея текстового редактора, мы не сможем редактировать исходный текст на языке программирования. Важно
- 84. Компилятор Итак, у нас есть исходный текст, написанный на языке программирования. Он составлен в соответствиями с
- 85. Интерпретатор Интерпретатор тоже преобразует текст на языке высокого уровня, но делает это построчно. Как только первая
- 86. Компоновщик Компоновщик, известный так же как редактор связей, (linker, link editor) занимается созданием готового исполняемого файла
- 87. Отладчик Отладчик или дебаггер является модулем среды разработки или отдельным приложением, предназначенным для поиска ошибок в
- 88. Генератор документации Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация
- 89. Инструментальные средства разработки клиент-серверных приложений Любое клиент-серверное приложение состоит из клиентского и серверного приложений. Соответственно этому
- 90. Инструментальные средства для разработки клиентской части Клиентской называется часть приложения, с которой напрямую взаимодействует конечный пользователь.
- 92. Скачать презентацию
Контрольные точки работы
1 модуль. Презентация должна содержать в себе постановку задачи
Контрольные точки работы
1 модуль. Презентация должна содержать в себе постановку задачи
2 модуль. Работающее ПО, презентация должна содержать в себе демонстрацию разработанного ПО (2 балла), расчет финансовых показателей проекта (1 балл), соответствие выполненных работ плану выполнения проекта (2 балла), оценку текущего состояния проекта и перспектив его развития (1 балл). Дополнительные баллы проставляются за ответы на вопросы преподавателя (2 балла) и студентов (1 балл), качество выполнения презентации (1 балла).
Рекомендуемая литература
Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем:
Рекомендуемая литература
Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем:
Брукс Ф. Мифический человеко-месяц / Символ, С-Пб.: 2000.
Липаев В.В. Системное проектирование сложных программных средств для информационных систем / Синтег, М.: 1999.
Рейнвотер Дж. Как пасти котов. Наставление для программистов, руководящих другими программистами / СПб.: Питер. 2006. С. 256.
Йордон Э. Путь камикадзе / Лори, М.: 2003.
Глаголев В. Разработка технической документации. СПб.: Питер, 2008. – 192 с.
ГОСТ 34.601-90
ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207).
Благодатских В.А., Волнин В.А., Поскалоф К.Ф. Стандартизация разработки программных средств. М.: Финансы и статистика, 2007. – 288 с.
Лекция 1. Программное обеспечение компьютерных систем
ПО и его классификации
ПО – совокупность
Лекция 1. Программное обеспечение компьютерных систем
ПО и его классификации
ПО – совокупность
технология проектирования программ;
методы тестирования программ;
анализ качества работы программ;
документирование программ.
Сфера применения ПО
ПО современных компьютеров включает миллионы программ – от игровых
Сфера применения ПО
ПО современных компьютеров включает миллионы программ – от игровых
Базовое (системное) ПО;
Рабочее (прикладное) ПО;
Инструментальное ПО (средства разработки ПО – СУБД реляционные (Oracle, MySQL), объектно-ориентированные, иерархические, сетевые).
Классификация ПО по способу распространения
Коммерческое ПО;
Бесплатные программы;
Условно-бесплатные (их можно получить и
Классификация ПО по способу распространения
Коммерческое ПО;
Бесплатные программы;
Условно-бесплатные (их можно получить и
Пиратские (ворованные) копии программ (не имеют документации).
Пакеты прикладных программ
ППП – комплект программ, предназначенных для решения задач в
Пакеты прикладных программ
ППП – комплект программ, предназначенных для решения задач в
Выделяет следующие виды ППП:
проблемно-ориентированные (где возможна типизация функций управления) – ППП автоматизации бухучета, управления персоналом;
Автоматизации проектирования (в работе конструкторов – разработка чертежей);
Общего назначения (графические редакторы, СУБД);
Офисные;
Системы искусственного интеллекта (экспертные системы, поддержка общения на естественном языке).
Программные средства и продукты
Программные средства – математические средства, с помощью которых
Программные средства и продукты
Программные средства – математические средства, с помощью которых
Программный продукт – совокупность отдельных программных средств, их документации, гарантий качества, рекламных материалов, мер по обеспечению пользователей, распространению и сопровождению готового ПО.
Программное изделие – программа или логически связанная совокупность программ, записанная на носителях данных, являющаяся продуктом промышленного производства, снабженная программной документацией, предназначенная для широкого распространения посредством продажи.
При этом путь от «программ для себя» до программных продуктов достаточно долгий. Программные продукты могут создаваться как индивидуальная разработка под заказ, разработка для массового распространения среди пользователей.
При индивидуальной разработке фирма-разработчик создает оригинальный программный продукт, учитывающий специфику обработки
При индивидуальной разработке фирма-разработчик создает оригинальный программный продукт, учитывающий специфику обработки
При разработке для массового распространения фирма-разработчик, с одной стороны, должна обеспечить универсальность выполняемых функций обработки данных, с другой стороны, гибкость и настраиваемость программного продукта на условия конкретного применения.
Программный продукт создается на основе промышленной технологии выполнения проектных работ с применением современных инструментальных средств программирования. Специфика заключается в уникальности процесса разработки алгоритмов и программ. На создание программных продуктов затрачиваются значительные ресурсы – трудовые, материальные, финансовые, требуется высокая квалификация разработчиков.
Как правило, программные продукты требуют сопровождения, которое осуществляется специализированными фирмами – распространителями программ (дистрибьюторами). Сопровождение программ массового применения сопряжено с большими трудозатратами – обнаружение и исправление ошибок, создание новых версий программ и т.п.
Рынок программных продуктов
На рынке ПП действуют:
Поставщики ПП;
Потребители ПП;
Посредники.
В условиях существования рынка
Рынок программных продуктов
На рынке ПП действуют:
Поставщики ПП;
Потребители ПП;
Посредники.
В условиях существования рынка
Стоимость;
Количество продаж;
Время нахождения на рынке;
Известность фирмы-разработчика и программы;
Наличие ПП аналогичного назначения.
Маркетинг
ПП массового распространения продаются по ценам, которые учитывают конъюнктуру рынка (наличие
Маркетинг
ПП массового распространения продаются по ценам, которые учитывают конъюнктуру рынка (наличие
Формирование политики цен для завоевания рынка;
Широкую рекламную компанию ПП;
Создание торговой сети для реализации ПП (дилеры и дистрибьюторы);
Обеспечение сопровождения и гарантийного обслуживания ПП, создание горячей линии;
Обучение пользователей ПП.
Спецификой ПП является также и то, что их эксплуатация должна выполняться на правовой основе – лицензионные соглашения между разработчиком и пользователями с соблюдением авторских прав разработчиков ПП.
Приобретение программного продукта – это покупка лицензии – права на его
Приобретение программного продукта – это покупка лицензии – права на его
Каждый пользователь ПП должен иметь лицензию на него. Лицензия должна быть закуплена для каждого компьютера, на котором установлен или используется через сеть ПП. Договор между пользователем и производителем не подписывается: считается, что покупатель соглашается с условиями лицензионного соглашения, если он вскрывает дистрибутив – упаковку с компакт-диском. Это так называемая «оберточная лицензия», предусмотренная Законом «О правовой охране программ для ЭВМ и баз данных» от 23 сентября 1992 г.
Лицензия
ПО на компьютере находится в «пользовании», когда оно помещено в постоянную
Лицензия
ПО на компьютере находится в «пользовании», когда оно помещено в постоянную
Приобретение лицензии
Существует несколько вариантов приобретения лицензии. Наиболее известный и распространенный путь
Приобретение лицензии
Существует несколько вариантов приобретения лицензии. Наиболее известный и распространенный путь
Лекция 2
Разработка ПС
Стадии разработки ПО, регламентированные ГОСТ
В РФ ЖЦ разработки ПО
Лекция 2
Разработка ПС
Стадии разработки ПО, регламентированные ГОСТ
В РФ ЖЦ разработки ПО
ТЗ
Эскизный проект (ЭП)
Технический проект (ТП)
Рабочий проект (РП)
Внедрение
Техническое задание
На стадии ТЗ выполняются следующие работы, входящие в состав соответствующих
Техническое задание
На стадии ТЗ выполняются следующие работы, входящие в состав соответствующих
Обоснование необходимости разработки программ: постановка задачи, сбор исходных материалов, выбор и обоснование критериев эффективности и качества.
Выполнение НИР: определение структуры входных и выходных данных, предварительный выбор методов решения задач, обоснование целесообразности применения ранее разработанных программ,определение требований к техническим средствам, обоснование возможности решения поставленных задач.
Разработка и утверждение ТЗ: определение требований к ПО, разработка технико-экономических показателей, определение стадий, этапов и сроков разработки ПО и документации на него, выбор языков программирования, согласование и утверждение ТЗ.
Эскизный проект
Результатом выполнения данной стадии является полное описание архитектуры ПО. Как
Эскизный проект
Результатом выполнения данной стадии является полное описание архитектуры ПО. Как
Технический проект
Содержанием работ по этой стадии является проектирование структуры ПО. Результатом
Технический проект
Содержанием работ по этой стадии является проектирование структуры ПО. Результатом
Рабочий проект
Содержанием работ на этой стадии является описание ПО на выбранном
Рабочий проект
Содержанием работ на этой стадии является описание ПО на выбранном
Качество ПО
Качество ПО – способность ПО подтвердить свою спецификацию при условии,
Качество ПО
Качество ПО – способность ПО подтвердить свою спецификацию при условии,
Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Методологии и стандартизации оценки характеристик качества программных средств на различных этапах жизненного цикла посвящен международный стандарт ISO 14598.
Рекомендуется следующая общая схема процессов оценки характеристик качества программ:
Функциональная пригодность –
Рекомендуется следующая общая схема процессов оценки характеристик качества программ:
Функциональная пригодность –
Оценка корректности программных средств состоит в формальном определении степени соответствия комплекса реализованных программ исходным требованиям контракта, ТЗ и спецификаций на программное средство. Путем верификации должно быть определено соответствие исходным требованиям всей совокупности компонентов комплекса программ, вплоть до модулей и текстов программ с описанием данных.
Оценка способности к взаимодействию состоит в определении качества совместной работы компонентов программных средств и БД с другими прикладными системами и компонентами на различных вычислительных платформах, а также взаимодействия с пользователями в стиле, удобном для перехода от одной вычислительной системы к другой с подобными функциями.
Оценка защищенности программных средств включает определение полноты использования доступных методов и
Оценка защищенности программных средств включает определение полноты использования доступных методов и
Оценка надежности – измерение количественных метрик к таким показателям как завершенность, устойчивость к дефектам, восстанавливаемость.
Потребность в ресурсах памяти и производительности компьютера в процессе решения задач значительно изменяется в зависимости от состава и объема исходных данных. Для корректного определения предельной пропускной способности информационной системы нужно измерить экстремальные и средние значения длительности исполнения программ.
Оценка практичности программных средств проводится экспертами и включает определение понятности, простоты
Оценка практичности программных средств проводится экспертами и включает определение понятности, простоты
Сопровождаемость можно оценивать полнотой и достоверностью документации на ПО. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные.
Оценка мобильности – подготовленность ПС к переносу на другую платформу.
Надежность ПО
Надежность ПО – способность ПП безотказно выполнять определенные функции при
Надежность ПО
Надежность ПО – способность ПП безотказно выполнять определенные функции при
Степень надежности характеризуется вероятностью работы ПП без отказа в течение определенного периода времени.
Источниками ненадежности являются непроверенные сочетания исходных данных, при которых отлаженные программы дают неверные результаты и отказы.
Отказ – нарушение работоспособности ПО, являющееся следствием таких явлений, как нарушение кодов записи программ в памяти, стирания или искажения данных в оперативной или долговременной памяти, нарушения нормального хода вычислительного процесса.
Сбой – самоустраняющийся отказ, не требующий внешнего вмешательства. Основное различие между сбоем и отказом – по временному показателю длительности восстановления. Если длительность восстановления больше какого-то порогового значения, то аномалию в работе ПО относят к отказам, иначе – к сбоям.
Понятие корректной программы рассматривается статически вне времени функционирования. Неправильность программы определяется
Понятие корректной программы рассматривается статически вне времени функционирования. Неправильность программы определяется
Попадания исходных данных в область непроверенных при отладке и испытаниях;
Проявления ошибки в программе при обработке таких данных.
Правильность программы не зависит от динамики функционирования в реальном времени.
Правильность ПО
Надежная программа должна обеспечивать низкую вероятность отказа в процессе функционирования. Количество
Надежная программа должна обеспечивать низкую вероятность отказа в процессе функционирования. Количество
Число ошибок в программе – величина «ненаблюдаемая», наблюдаются не сами ошибки, а результат их появления.
Неверное срабатывание программы может быть следствием не одной, а сразу нескольких ошибок.
Ошибки могут компенсировать друг друга, так что после исправления какой-то одной ошибки программа может начать «работать хуже».
Надежность характеризует частоту проявления ошибок, но не их количество. Неверное срабатывание программы = нулевая надежность.
Лекция 3
Жизненный цикл ПО
Жизненный цикл (ЖЦ) программной системы – это последовательность
Лекция 3
Жизненный цикл ПО
Жизненный цикл (ЖЦ) программной системы – это последовательность
анализ;
проектирование;
разработка;
тестирование;
развертывание;
использование.
Варианты жизненного цикла программ
Варианты жизненного цикла программ
Варианты жизненного цикла программ
Также различают различные виды жизненных циклов и проектирования
Варианты жизненного цикла программ
Также различают различные виды жизненных циклов и проектирования
При проектировании сверху вниз проводится общий анализ системы: определяются входные и
При проектировании сверху вниз проводится общий анализ системы: определяются входные и
При восходящем проектировании на начальном этапе проектируются самостоятельные системы. После этого проектировщик пытается объединить их между собой таким образом, чтобы получить связанные подсистемы, обладающие большей функциональностью. Подобное объединение производится до тех пор, пока не будет получен модуль, обладающий требуемой функциональностью.
Метод расширения ядра заключается в том, что проектировщик выделяет наиболее важный, с его точки зрения, модуль и производит его проектирование. Далее проектируются модули, которые расширяют функциональность имеющегося в заданном направлении, производится их объединение. Таким образом, на каждом этапе проектирования в наличии имеется система с ограниченной функциональностью.
При смешанных методиках возможны комбинации указанных подходов. Так, например, в начале работ могут быть определены основные универсальные блоки, которые потребуются при создании системы. После их проектирования начинается проектирование сверху вниз, причем при проектировании функциональности блоков учитывается возможность включения в них уже разработанных универсальных.
Распределение работ
Существует эмпирический закон, который гласит, что в процессе создания ПО
Распределение работ
Существует эмпирический закон, который гласит, что в процессе создания ПО
Анализ
Этап анализа требований посвящен работе с заказчиком. На данном этапе заказчик
Анализ
Этап анализа требований посвящен работе с заказчиком. На данном этапе заказчик
Двумя крайними случаями при анализе требований могут быть либо постановка задачи «Сделайте нам работающую систему», либо навязывание разработчикам приемов и методов, а также строгого собственного видения функциональности системы. В первом случае реакцией заказчика на готовый продукт может быть: «Это совсем не то, что мы ожидали. Мы думали, что вы профессионалы и можете разработать нормальную систему». Во втором случае может выясниться, что система не может быть разработана при существующих требованиях по соображениям технического (например, завышенные требования к производительности) либо экономического (например, быстрое создание сложной высококачественной хорошо задокументированной и передаваемой системы за минимальные деньги) плана.
Анализ. Разработка требований и внешнее проектирование ПО
1. Общая схема создания ПО
Процесс
Анализ. Разработка требований и внешнее проектирование ПО
1. Общая схема создания ПО
Процесс
Постановка задачи
Алгоритмизация решения задачи
Программирование
Постановка задачи
это точная формулировка решения задачи на компьютере с описанием входной
Постановка задачи
это точная формулировка решения задачи на компьютере с описанием входной
К основным характеристикам функциональных задач, уточняемым в процессе ее формализованной постановки, относятся:
Цель и назначение задачи, ее место и связи с другими задачами;
Условия решения задачи с использованием средств вычислительной техники;
Содержание функций обработки входной информации при решении задачи;
Требования к периодичности решения задачи;
Ограничения по срокам и точности выходной информации;
Состав и форма представления выходной информации;
Источники входной информации для решения задачи;
Пользователи задачи
Алгоритм
Система точно сформулированных правил, определяющая процесс преобразования допустимых исходных данных в
Алгоритм
Система точно сформулированных правил, определяющая процесс преобразования допустимых исходных данных в
Обязательные свойства алгоритмов:
Дискретность
Определенность
Выполнимость
Массовость
В алгоритме обязательно должны быть предусмотрены все ситуации, которые могут возникнуть в процессе решения.
Программирование
Программа – реализованной алгоритм на языке программирования.
Наиболее часты программисты делятся на
Программирование
Программа – реализованной алгоритм на языке программирования.
Наиболее часты программисты делятся на
В условиях создания больших по масштабам и функциям обработки программ существует квалификация – программист-аналитик, который анализирует и проектирует комплекс взаимосвязанных программ для реализации функций предметной области.
В процессе создания программ на начальной стадии работ участвуют и специалисты – постановщики задач.
Большинство информационных систем основано на работами с БД. Если БД является интегрированной, обеспечивающей работу с данными многих приложений, возникает проблема организационной поддержки БД, которая выполняется администратором БД.
Основным потребителем программ служит конечный пользователь, который не является специалистом в области программирования, что влияет на спецификацию требований к ПО, интерфейсам и т.д.
2. Разработка требований к ПО
Наиболее оптимальной является совместная работа проектировщиков и
2. Разработка требований к ПО
Наиболее оптимальной является совместная работа проектировщиков и
Можно установить 2 фазы по выработке требований:
Фаза планирования. Определяется реализуемость, устанавливаются цели, оцениваются затраты, обеспечивается ориентация для разработки проекта.
Фаза выработки требований пользователя. Вырабатываются требования к входным данным, информационным потокам, выходным данным, документации, среде, вычислительным ресурсам.
3. Цели разработки ПО
Цели разработки обычно включают следующую информацию:
Краткое описание ПО
3. Цели разработки ПО
Цели разработки обычно включают следующую информацию:
Краткое описание ПО
Определение круга пользователей
Подробное описание функциональных задач
Документация. Определяются типы документации и предполагаемый круг читателей для каждого типа.
Эффективность. Временные характеристики, использование ресурсов.
Совместимость
Конфигурация
Безопасность
Обслуживание
Установка
Надежность. Сбои и их последствия
4. Разработка внешних спецификаций проекта
Внешнее проектирование – это процесс описания планируемого
4. Разработка внешних спецификаций проекта
Внешнее проектирование – это процесс описания планируемого
Разработка внешних спецификаций разбивается на 2 части:
Предварительный внешний проект
Детальный внешний проект
Предварительный внешний проект содержит описание основных компонентов и внешних функций, составляющих
Предварительный внешний проект содержит описание основных компонентов и внешних функций, составляющих
Детальный внешний проект должен включать следующую информацию:
Описание входных данных (точное описание синтаксиса и семантики всех данных, вводимых пользователем).
Описание выходных данных (точное описание результатов функций).
Характеристики надежности (описание влияния всевозможных отказов).
Эффективность
Замечания по программированию
Лекция 5
Проектирование и разработка
Пользовательский интерфейс является своеобразным коммуникационным каналом, по которому
Лекция 5
Проектирование и разработка
Пользовательский интерфейс является своеобразным коммуникационным каналом, по которому
Лучший пользовательский интерфейс – это такой интерфейс, которому пользователь не должен уделять много внимания или почти не замечать его.
Общие принципы проектирования пользовательских интерфейсов
Программа должна помогать выполнить задачу, а не
Общие принципы проектирования пользовательских интерфейсов
Программа должна помогать выполнить задачу, а не
При работе с программой пользователь не должен ощущать себя дураком.
Программа должна работать так, чтобы пользователь не считал компьютер дураком.
Графический интерфейс пользователя
Графический интерфейс пользователя (GUI) является обязательным компонентом большинства современных
Графический интерфейс пользователя
Графический интерфейс пользователя (GUI) является обязательным компонентом большинства современных
Наиболее GUI реализуется в интерактивном режиме работы пользователя для программных продуктов, функционирующих в среде Windows, и строится в виде системы спускающихся меню с использованием в качестве средства манипуляции мыши и клавиатуры. Работа пользователя осуществляется с экранными формами, содержащими объекты управления, панели инструментов с пиктограммами режимов и команд обработки.
Формы
Формы – это строительные блоки интерфейса пользователя.
Формы делятся на два вида:
Формы
Формы – это строительные блоки интерфейса пользователя.
Формы делятся на два вида:
Виды интерфейса:
Однодокументный (SDI);
Мнодокументный (MDI).
В SDI-приложениях окна форм появляются совершенно независимо друг от друга.
Диалоговый режим
Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя,
Диалоговый режим
Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя,
В диалоговом режиме под воздействием пользователя осуществляется запуск функций (методов) обработки, изменение свойств объектов, производится настройка параметров выдачи информации на печать и т.п.
Системы, поддерживающие диалоговые процессы, классифицируются на:
Системы с жестким сценарием диалога –
Системы, поддерживающие диалоговые процессы, классифицируются на:
Системы с жестким сценарием диалога –
Дескрипторные системы – формат ключевых слов сообщений;
Тезаурусные системы (аналог – гипертекстовые системы);
Системы с языком деловой прозы – представление сообщений на языке, естественном для профессионального пользования.
Диалоговые системы с жестким сценарием диалога
Наиболее просты для реализации и распространены
Диалоговые системы с жестким сценарием диалога
Наиболее просты для реализации и распространены
Меню – диалог инициируется программой; пользователю предлагается выбрать вариант из перечня.
Действия запрос-ответ – фиксирован перечень возможных значений, выбираемых из списка, или ответы типа Да/Нет;
Запрос по формату – с помощью ключевых слов, фраз осуществляется подготовка сообщений.
Диалоговый процесс управляется согласно созданному сценарию, для которого определяются:
Точки начала диалога
инициатор диалога (человек или программа)
параметры и содержание диалога
Разработка
Собственно разработка ПО заключается в детальном проектировании отдельных работ и их
Разработка
Собственно разработка ПО заключается в детальном проектировании отдельных работ и их
С точки зрения менеджера проекта при разработке программного обеспечения следует помнить, что кризисную ситуацию чаще проще предотвратить, чем найти пути выхода из нее. Это означает, что в ходе разработки следует внимательно относиться к выполнению всех сроков, требований по качеству и функциональности продукта, объему его функций. Менеджер проекта интересуется деталями хода проекта до наступления контрольных точек, чтобы к их наступлению все работы были завершены.
Также менеджеру следует помнить, что увеличение длительности рабочей недели не всегда
Также менеджеру следует помнить, что увеличение длительности рабочей недели не всегда
С точки зрения разработчика следует помнить, что качество программного кода закладывается именно в момент его написания. Чем меньше ошибок допустит сам программист, чем больше времени он потратит на проверку кода и его проработку, тем меньше шансов найти в нем какой-либо изъян. Зачастую здесь может помочь «метод пристального взгляда», когда уже по окончании разработки кода программист повторно просматривает собственный код, причем возможно даже в распечатках.
Выражаясь метафорично, основным девизом этапа разработки является «Контроль над всем». Менеджер должен контролировать соответствие разработки календарному плану и разработанным требованиям. Программисты должны следить за качеством и безопасностью разрабатываемого ими кода. Тестировщики должны отслеживать соответствие продукта его функциональности и требованиям. Составители документации и инженерные психологи должны контролировать удобство использования системы.
Тестирование ПО
Роль этапа тестирования зачастую незаслуженно принижается. Однако ошибки в программном
Тестирование ПО
Роль этапа тестирования зачастую незаслуженно принижается. Однако ошибки в программном
Для менее опытных программистов принята следующая статистика. Один программист делает в ходе работы от 0,5 до 3 ошибок на строчку кода. В результате устранения указанных в ходе работы компилятора ошибок в коде остается порядка 1 ошибки на 10 строчек кода. Отладка программы сокращает количество ошибок до 1 на 100 строк кода. Тестирование кода специально выделенным сотрудниками с последующей коррекцией кода снижает число ошибок до 1 на 1000 строк. Эти цифры принято брать за основу при планировании разработки.
По данным Microsoft устранение одной ошибки, требующей создания пресс-релиза и пакета обновлений, обходится фирме примерно в 100 000$.
Виды тестирования
Существует несколько видов тестирования. Начальное тестирование проводится непосредственно разработчиками для
Виды тестирования
Существует несколько видов тестирования. Начальное тестирование проводится непосредственно разработчиками для
Под регрессионным тестированием понимается последовательный прогон всех тестов, которые запускались для данного продукта до сих пор. Задачей регрессионного тестирования является проверка функциональности уже включенных модулей. Модули, которые не прошли тестирование, отправляются на доработку.
Кроме того, тестирование делят на тестирование методом черного, серого и белого ящиков. В первом случае тестировщик не имеет никакой информации о структуре тестируемой системы и описывает только симптомы неисправности, при этом он может высказывать предположения о причинах возникновения неисправности. В последнем случае тестировщик обладает полным исходным кодом программы и может указывать конкретные строки кода, вызвавшие сбой. Тестирование методом серого ящика является промежуточным вариантом – тестировщик имеет представление о составе модулей тестируемой системы, однако не имеет информации об их внутренней структуре или особенностях реализации.
Функциональное тестирование преследует своей целью проверку корректности работы приложения. В таком
Функциональное тестирование преследует своей целью проверку корректности работы приложения. В таком
Нагрузочное тестирование служит для проверки функционирования системы в экстремальных условиях: нехватка оперативной или внешней памяти, потери канала связи или соединения с другим приложением, работа с поврежденными файлами и так далее. При этом программа должна проявлять устойчивость и безопасность.
Тестирование функциональности пользовательского интерфейса проводится с целью определения соответствия действий, привязанных к элементам управления, требованиям, заявленным в документации. То есть любая функция должна быть доступна именно тем методом, который был заявлен.
Тестирование удобства пользовательского интерфейса проводится скорее инженерными психологами, чем тестировщиками. Здесь психологи проверяют насколько приятно и удобно пользоваться данной программой, очевиден ли ее интерфейс, нельзя ли его улучшить.
При исправлении ошибки следует помнить несколько стандартных подходов.
Повторный просмотр кода резко снижает количество ошибок, обнаруженных на этапе тестирования.
Обычно программисты делают примерно одни и те же «любимые» ошибки. При обнаружении одной из них проверьте код на предмет обнаружения других аналогичных. Здесь, как и везде, действует принцип 80/20 – 80% ошибок встречаются в 20% кода.
Копирование кода является методом повышения производительности и количества ошибок.
Нет ничего постояннее, чем временное. Если вы не запишите себе в список задач доработку временного кода, есть большая вероятность получить от отдела тестирования запись в свой список ошибок.
Развертывание ПО
Развертывание приобретает высокую актуальность для больших систем. В простейшем случае
Развертывание ПО
Развертывание приобретает высокую актуальность для больших систем. В простейшем случае
Например, сложные системы АСУ ТП обычно доводятся непосредственно у заказчика, так как различные предприятия обладают собственной спецификой. При внедрении нового оборудования и программных систем перед началом работ производится обучение персонала. В конечном итоге должна быть произведена приемка продукта с подписанием соответствующих актов.
Развертывание сложной системы может оказаться трудоемким и затратным процессом, который необходимо предусмотреть еще на этапах анализа требований и проектирования. Так, например, может оказаться, что заказчиком не предусмотрены средства для развертывания системы и весь проект окончится провалом. Кроме того, может выясниться, что развертывание комплекса в существующих условиях просто невозможно. Также может выясниться, что развертывание комплекса может быть слишком затратным мероприятием, стоимость которого превышает саму стоимость разработки.
Сопровождение ПО
Сопровождение ПО также следует предусмотреть еще на этапе проектирования, так
Сопровождение ПО
Сопровождение ПО также следует предусмотреть еще на этапе проектирования, так
Лекция
Документация ПО
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается
Лекция
Документация ПО
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается
Надо сказать, что наряду с комплексом ЕСПД официальная нормативная база РФ в области документирования ПО и в смежных областях включает ряд перспективных стандартов (отечественного, межгосударственного и международного уровней), например, Международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла ПО.
Перечень документов ЕСПД
ГОСТ 19.001-77 ЕСПД. Общие положения.
ГОСТ 19.101-77 ЕСПД. Виды программ
Перечень документов ЕСПД
ГОСТ 19.001-77 ЕСПД. Общие положения.
ГОСТ 19.101-77 ЕСПД. Виды программ
ГОСТ 19.102-77 ЕСПД. Стадии разработки.
ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
ГОСТ 19.104-78 ЕСПД. Основные надписи.
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
ГОСТ 19.106-78 ЕСПД. Общие требования к программным документам, выполненным печатным способом.
ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.
ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
ГОСТ 19.402-78 ЕСПД. Описание программы.
ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к
ГОСТ 19.402-78 ЕСПД. Описание программы.
ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к
ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
ГОСТ 19.504-79 ЕСПД. Руководство программиста.
ГОСТ 19.505-79 ЕСПД. Руководство оператора.
ГОСТ 19.506-79 ЕСПД. Описание языка.
ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.781-90. Обеспечение систем обработки информации программное.
Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также
Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также
ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения.
Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области ПО, систем обработки данных.
ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения.
Распространяется не только на программные, но и на конструкторские, технологические и другие документы, выполняемые на магнитных носителях.
ГОСТ Р ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием ПО.
ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции, характеристика качества и руководство по их применению.
ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения
ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения
ГОСТ Р ИСО/МЭК 8631:1994. Информационная технология. Пакеты программных средств. Требования к качеству и испытания.
ГОСТ Р ИСО/МЭК 12207-99. Процессы жизненного цикла программных средств.
ISO 12207:1995. (ГОСТ Р-1999). ИТ. Процессы жизненного цикла программных средств.
ISO 15271:1998. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207.
ISO 16326:1999. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.
ISO 9126:1991. (ГОСТ-1993). ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению.
ISO 12119:1994. (ГОСТ Р-2000). ИТ. Требование к качеству и тестирование.
ISO 13210:1994. (ГОСТ Р-2000). ИТ. Методы тестирования для измерения соответствия стандартам POSIX.
Стандарт ISO 9000
Это целая группа стандартов, предъявляющая требования к процессу разработки,
Стандарт ISO 9000
Это целая группа стандартов, предъявляющая требования к процессу разработки,
Первый вариант международного стандарта 9000-й серии был опубликован Международной организацией стандартов (ISO) в 1987 г., после чего он два раза пересматривался. Сегодня действующий вариант — ISO 9001:2008. Существенным отличием новой редакции стандарта от предыдущих является требование непрерывного улучшения качества и подход к описанию предприятия на основе бизнес-процессов.
ISO 9001:2008 устанавливает требования к системе менеджмента качества, которые предназначены для внутреннего применения организациями в целях сертификации или заключения контрактов. Он направлен на обеспечение эффективности системы менеджмента качества и формулирует минимальный набор условий, которым она должна удовлетворять для выполнения установленных требований к продукции. Соответствие стандарту ISO 9001:2008 может также использоваться организацией для демонстрации своей способности удовлетворить нужды и чаяния потребителей.
ISO 9004:2009 предоставляет методическую помощь по более широкому спектру целей системы
ISO 9004:2009 предоставляет методическую помощь по более широкому спектру целей системы
Стандарт ISO 9001:1994 - Система качества. Модель для обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании - предлагает оценивать способность поставщика не только успешно проектировать изделия, но также производить их и испытывать. В стандарте подробно изложены 20 групп требований к системе качества и ее компонентам, рубрикация которых используется и в других документах. Определена ответственность руководства за политику и организацию в области качества, представлены общие требования к управлению проектированием, документацией и проведением испытаний. Сформулированы правила регистрации данных о качестве, контроле и корректировках качества продукции, о подготовке специалистов в области качества.
Система качества
Функционирование и применение системы качества на предприятии - разработчике ПС
Система качества
Функционирование и применение системы качества на предприятии - разработчике ПС
В процессе проверки системы качества анализируется наличие планов и методик проведения внутренних проверок и документально оформленных их результатов, обеспечивающих:
выявление причин несоответствий продукций и корректирующих действий, предупреждающих повторное возникновение дефектов;
анализ всех процессов, рабочих операций, отклонений, протоколов качества, отчетов об использовании продукции и рекламаций потребителя с целью выявления и устранения возможных причин дефектов продукции;
проведение предупреждающих действий для предотвращения дефектов на том уровне, который соответствует реальному риску;
проведение контроля с целью проверки реализации и эффективности корректирующих действий.
Облегченные методики разработки ПО
Классические методики разработки ПО рассчитаны на то, что
Облегченные методики разработки ПО
Классические методики разработки ПО рассчитаны на то, что
Здесь мы подробно рассмотрим три методики разработки ПО: спиральная разработка, экстремальное программирование и технология SCRUM.
Спиральная модель разработки
Спиральная модель разработки ПО построена следующим образом. На начальных
Спиральная модель разработки
Спиральная модель разработки ПО построена следующим образом. На начальных
На каждой итерации рекомендуется придерживаться следующих шагов.
Формирование видения проблемы. В ходе
На каждой итерации рекомендуется придерживаться следующих шагов.
Формирование видения проблемы. В ходе
Расстановка приоритетов. Требования, предъявляемые заказчиком к системе могут оказаться противоречивыми. Кроме того, может оказаться затруднительно реализовать сразу всю намеченную функциональность за один этап.
Согласование временных рамок проекта. На данном этапе по составленному объему работ определяется общее время, необходимое на выполнение этапа. Часто при фиксированных сроках оговаривается, какую часть работ разработчик сумеет выполнить в соответствии с расставленными приоритетами.
Определение архитектуры и ядра будущей системы. Ядро системы здесь – это законченный работающий вариант системы с урезанной функциональностью. С заказчиком оговаривают особенности функционирования системы в общем, а также особенности работы основных (наиболее важных) фрагментов. Далее определяется функциональность подсистем с более низкими приоритетами.
Формирование плана выполнения итерации. В соответствии с оговоренными сроками и функциональностью производится планирование работ в рамках итерации.
Разработка системы в соответствии с планом. На данном этапе производится создание самой системы. При этом в случаях отставание по срокам, сокращения финансирования или в других критических ситуациях, в соответствии с оговоренными приоритетами могут отбрасываться функции с низкими приоритетами.
Экстремальное программирование
Экстремальное программирование работает только в случае, если вы имеете небольшую
Экстремальное программирование
Экстремальное программирование работает только в случае, если вы имеете небольшую
Суть экстремального программирования состоит в обобщении отдельных этапов разработки на весь процесс. Это означает, что в ходе выполнения всего проекта выполняется его проектирование, уточнение требований, разработка, тестирование и отладка.
В основе экстремального программирования лежат 12 принципов. В сущности, экстремальное программирование может остаться таковым, даже если при реализации отбросить некоторые (но не большинство) из этих принципов. С другой стороны, применение одного-двух принципов не сделает разработку экстремальной.
При таком подходе резко возрастает роль менеджера, отвечающего за проект. Он должен уметь организовать работу таким образом, чтобы выполнялись все указанные выше принципы.
Экстремальное программирование рассчитано на создание не очень больших систем, для которых ясны пути их реализации.
Принципы экстремального программирования
1. Простота проектирования – сдаваемая система будет наиболее простой
Принципы экстремального программирования
1. Простота проектирования – сдаваемая система будет наиболее простой
2. Выбор приоритетов и управление рисками. На основе некоторых оценок принимается решение, какую функциональность следует сделать немедленно, а какую можно отсрочить.
3. Непрерывная интеграция – сборка продукта производится каждый день или по несколько раз в день.
4. Тестирование как методический прием – тестирование ведется непрерывно всеми членами команды. Программисты готовят тесты до того, как пишут программный код.
5. Небольшие релизы – разработчики выпускают работоспособные версии программы как можно чаще.
6. Выделенный пользователь – в состав команды входит представитель заказчика, отвечающий за проверку функциональности системы, ответы на вопросы о пожеланиях заказчика, выбор тех или иных решений, расстановку приоритетов.
7. Переоценка потребностей – программисты постоянно улучшают структуру проекта и кода (проводят рефакторинг), стараясь избегать повторной реализации сходного кода. При этом разделяют стадии дизайна и рефакторинга. Просмотр кода на предмет его улучшения производится только над стабилизированным кодом.
8. Взаимодействие – каждый из сотрудников должен уметь синхронизировать свою работу с действиями других. При этом каждый должен понимать структуру всего проекта.
9. Система имен – в ходе разработки используется единая терминология.
10. Парная разработка – программисты пишут код парами, вплоть до работы пары за одним компьютером. Пока один пишет код, второй работает над архитектурой.
11. Коллективное владение – код не принадлежит никому из команды, каждый член команды может работать над любым фрагментом кода.
12. 40-часовая рабочая неделя – усталые программисты делают больше ошибок.
Методология SCRUM
Методология SCRUM основывается на проведении недлинных (порядка 30 рабочих
Методология SCRUM
Методология SCRUM основывается на проведении недлинных (порядка 30 рабочих
Кроме бэклога на конкретный спринт ведется бэклог проекта в целом. За добавление и удаление функций, входящих в бэклог, отвечает только один человек в команде, хотя сами новые требования могут поступать из различных источников.
В ходе выполнения спринта проводятся ежедневные собрания. Основной задачей таких собраний
В ходе выполнения спринта проводятся ежедневные собрания. Основной задачей таких собраний
Цель ежедневных встреч – убедиться, что работа выполняется правильно и наметить пути ее выполнения на будущее. Встречи длятся порядка 15 минут и не требуют от участников проекта значительных затрат. Игнорирование ежедневных встреч приводит к снижению темпов работ и может вызвать крах проекта.
Методика не предусматривает деления процесса разработки на фиксированные этапы и/или группы. В ходе собраний в начале спринта разработчики решают, какие работы им необходимы на следующем этапе. Сами работы при этом оцениваются в функциональных возможностях проекта. Тестирование и документирование при этом рекомендуется осуществлять параллельно с работами по программированию проекта.
Методика SCRUM в большей степени ориентирована на создание больших и сложных систем, для которых требования не могут быть определены изначально. При грамотной постановке работ повышение производительности программистов может составлять до 600%. Однако при этом следует учитывать, что одной из рекомендаций методологии SCRUM является отсутствие конечных сроков сдачи продукта и его бюджета, что существенно повышает шансы проекта на успех.
Персональный процесс разработки
До сих пор мы рассматривали процесс разработки с точки
Персональный процесс разработки
До сих пор мы рассматривали процесс разработки с точки
Методикой, поясняющей как этого добиться, является персональный процесс разработки программного обеспечения – PSP. Методика PSP предлагает 7 этапов, проходя которые программист может улучшить собственный процесс.
В целом при работе по методике PSP программист проходит несколько стадий. При обучении любой деятельности в самом начале обучения человек бессознательно некомпетентен. Ситуация напоминает диалог. «Ты на скрипке играть умеешь» - «Не знаю, не пробовал». Человек не осознает свои возможности, которые чаще всего бывают существенно ниже необходимого уровня. После первых отрицательных результатов человек начинает осознавать собственный уровень, то есть становится сознательно некомпетентным. После долгих тренировок, решения уже практических задач, человек начинает осознавать в какой области он обладает знаниями, а в какой нет, то есть становится сознательно компетентным. Через некоторое время человек достигает вершин мастерства.
Задачей PSP является перевести программиста со второго уровня на третий и позволить ему как можно дольше оставаться на этом уровне для того, чтобы четко осознавать перспективы и направления собственного развития.
Этапы PSP
Этап PSP 0. На данном этапе программист учится составлять общий
Этапы PSP
Этап PSP 0. На данном этапе программист учится составлять общий
Этап PSP 0.1. На данном этапе программист учится измерять объем работ – строк кода программы в целом и ее отдельных модулей, страниц документации и т.д. Для каждой выполняемой задачи программист описывает объем работ, который ему пришлось выполнить для ее реализации, время которое он потратил на выполнение этого объема работ.
Этап PSP 1. На данном этапе программист учится оценивать размер будущей программы. При этом следует различать новый код (добавленный к существующему объекту, кодом нового объекта, измененным кодом объекта), повторно используемый код, базовый код прежней версии. При этом также следует учитывать, что разный код вносит разный вклад в итоговую оценку. Так, например, код, написанный на C, C++ и Visual Basic содержит обычно больше ошибок, чем код, написанный на Pascal.
Этапы PSP
Этап PSP 1.1. На данном этапе программист, на основе полученных
Этапы PSP
Этап PSP 1.1. На данном этапе программист, на основе полученных
Этап PSP 2. Данный этап учит программиста управлять качеством своего кода. Программист пытается предсказать количество ошибок, которые могут появиться в его коде. В ходе разработки программист сверяется с плановыми числами и при нахождении расхождений пытается выявить их причину. Основным методом для выявления ошибок является «метод пристального взгляда» – тщательное изучение собственного кода после того, как он был написан и прошел компиляцию, однако перед тем, как начнется его тестирование самим программистом (хотя данный метод можно применять и до запуска компилятора). Дело в том, что компилятор пропускает порядка 10% потенциальных ошибок – отсутствие break в операторе switch, strlen(str+1) и прочие. При этом время, необходимое на обнаружение ошибки в ходе финального тестирования, выше времени обнаружения ошибки в ходе просмотра кода на порядки. Если в ходе обзора кода ошибка находится за 5-20 минут, то в ходе тестирования на ее обнаружение уходит 15-30 минут, а в ходе комплексного тестирования – порядка 8 часов. Число ошибок на 1000 строк кода снижается примерно в 5 раз для ошибок, обнаруживаемых компилятором, и в 3 раза – обнаруживаемых при тестировании.
Этапы PSP
Этап PSP 2. Здесь программист учится качественно проектировать программу в
Этапы PSP
Этап PSP 2. Здесь программист учится качественно проектировать программу в
Этап PSP 3. Посвящен совершенствованию персонального процесса разработки. Здесь программист ставит себе некоторую цель по повышению своей производительности или улучшению качества кода. Далее определяются методы достижения этой цели, проводятся замеры характеристик работы, полученный характеристики анализируются и на их основе программист вырабатывает рекомендации по улучшению.
Уровни зрелости компании
Для оценки эффективности производства программными продуктами используют уровни зрелости
Уровни зрелости компании
Для оценки эффективности производства программными продуктами используют уровни зрелости
1. Начальный – отсутствует статистический контроль и управление, планирование и управление рабочим временем, затратами.
2. Повторяющиеся процессы – в организации проводится повторяющийся (регулярный) статистический контроль за общим состоянием проекта, его сроками, степенью соответствия проекта требованиям, стоимостью.
3. Определенные процессы – на основании имеющейся информации об уже завершенных проектах компания получает возможность более точно прогнозировать затраты на определенные процессы, пути их выполнение.
4. Управляемые процессы – компания проводит регулярные замеры и анализ производительности, в результате чего любой проект в всегда является полностью управляемым.
5. Оптимизированные процессы – все процессы, протекающие в компании, исследованы настолько, что появляется возможность произвести их оптимизацию.
1 Этап
Практически все компании, начинающие свою деятельность находятся на первом уровне
1 Этап
Практически все компании, начинающие свою деятельность находятся на первом уровне
Выходом из такой ситуации является введение управления проектом. Оно подразумевает предварительную выработку требований проекту, промежуточных планов выполнения, подбор инструментария, оптимально подходящего для работы над проектом. В ходе самого проекта должны выполняться выработанные промежуточные сроки либо производиться своевременная переоценка плана. Уровень руководства должен обладать актуальной информацией, проводить регулярные проверки, быть в курсе прогресса работ и возникающих проблем.
Кроме того, необходимо ввести постоянный контроль за качеством. Если проект выполняется в сроки, но не соответствует требованиям или не является функциональным, можно говорить о кризисной ситуации. Это связано с тем, что на доработку проекта потребуется дополнительное время, не предусмотренное планом и объемом финансирования. На заключительной стадии проекта несоответствие требованиям может привести также к тому, что клиент не примет выполненную работу.
2 Этап
Повторяющиеся процессы позволяют наладить управление процессом разработки, сделать его более
2 Этап
Повторяющиеся процессы позволяют наладить управление процессом разработки, сделать его более
Однако на данном этапе отсутствует полная точность. Это может быть связано с тем, что команда работает в новой для нее области и не представляет всех нюансов, которые могут возникнуть. Такая ситуация возникает в случае, когда команда не имеет достаточного опыта либо вторгается в новую область деятельности. Несмотря на это, проводится постоянное управление проектом, хотя сроки выполнения проекта могут корректироваться.
Для того, чтобы перейти на следующий уровень зрелости компания должна определить группы процессов, отделив процессы, в разработке которых команда имеет опыт, от тех, с которыми приходится сталкиваться впервые. Далее компания должна выбрать некоторую архитектуру разработки программного обеспечения, выбрать методики и методологии, наиболее подходящие для работы над проектом.
3,4,5 этапы
Переход к определенным процессам позволяет осуществлять разработку твердо представляя себе
3,4,5 этапы
Переход к определенным процессам позволяет осуществлять разработку твердо представляя себе
Но данные и управление на третьем уровне все еще остаются качественными, а не количественными.
Для перехода на четвертый уровень необходимо собирать все статистические данные по уже сделанным процессам и применять их в дальнейшем на этапе проектирования. При этом сбор статистической информации поручается руководящему звену компании, а в некоторых случаях – специально уполномоченным сотрудникам. Должны проводиться специальные оценки эффективности выполнения различных этапов проверки с последующим анализом и коррекцией планов при выполнении аналогичных работ.
На пятом уровне компания получает возможность оптимизировать проходящие в ней процессы. При этом твердо закреплены качественные и количественные характеристики, по которым проводятся измерения и оценки, сбор информации производится автоматически или при помощи автоматизированных средств, результаты анализа данных динамично используются в задачах планирования и прогнозирования. Данные на данном уровне собираются в единые хранилища информации, которые обеспечивают не только контроль за изменениями и документирование кода, но и поиск прецедентов, шаблонов, стандартных алгоритмов и решений. На данном уровне автоматизируется не только сбор информации, но и контроль качества, соответствия требованиям.
Лекция. Инструментальные средства разработки ПО. История
Несмотря на развитие инструментальных средств до
Лекция. Инструментальные средства разработки ПО. История
Несмотря на развитие инструментальных средств до
Новый этап развития программного обеспечения был подготовлен открытиями 70-х годов в области технологии программирования и может датироваться публикацией работы Боэма «Программная инженерия» в 1976 году. В этой работе вводилось понятие жизненного цикла ПО и обосновывалось, что основные затраты приводятся не на разработку программ и не на их отладку, а на сопровождение. В истории развития ПО выделяют 3 этапа.
История. 1 этап
На первом этапе основные затраты были связаны с кодированием
История. 1 этап
На первом этапе основные затраты были связаны с кодированием
История. 2 этап
Второй этап развития программных средств характеризуется увеличением размеров программ
История. 2 этап
Второй этап развития программных средств характеризуется увеличением размеров программ
История. 3 этап
Третий этап бы связан с обобщением и интеграцией найденных
История. 3 этап
Третий этап бы связан с обобщением и интеграцией найденных
Инструментальные средства разработки ПО
В процессе разработки программного обеспечения используется большое количество
Инструментальные средства разработки ПО
В процессе разработки программного обеспечения используется большое количество
Необходимые
компиляторы и ассемблеры;
редакторы текстов;
компоновщики или редакторы связей (linkers).
Часто используемые
утилиты автоматической сборки проекта;
отладчики;
программы создания файлов помощи (документации).
программы создания инсталляторов.
Специализированные
дизассемблеры;
Декомпиляторы.
Интегрированные среды разработки
Интегрированные среды разработки содержат большую часть из приведенных выше программ и позволяют упростить процесс создания приложений.
Текстовые редакторы
Не имея текстового редактора, мы не сможем редактировать исходный текст
Текстовые редакторы
Не имея текстового редактора, мы не сможем редактировать исходный текст
возможность сохранения документов в требуемом формате (поддержка нужных расширений и т.п.);
возможность подсветки синтаксиса (выделение ключевых слов, констант и т.п.);
возможность копирования, вставки, замены фрагментов текста;
возможность автодополнения вводимого текста, отображения вариантов для вызываемых функций и т.п.;
возможности автоформатирования вводимого текста (автоматически создавать отступы в теле функции и т.п.).
Поскольку работа с текстовым редактором занимает значительную часть всего времени разработки, правильный выбор текстового редактора может существенно ускорить или замедлить процесс редактирования исходных текстов. Кроме того, практически все интегрированные среды разработки используют свой редактор. Все эти редакторы имеют общие черты, но есть и отличия, по которым и формируется окончательное мнение человека о среде разработки в целом.
Если не рассматривать консольные редакторы (которые все еще популярны под операционными системами семейства UNIX), то можно с уверенностью сказать, что все редакторы, поддерживающие GUI (Graphical user unterface, графический интерфейс пользователя) имеют схожий пользовательский интерфейс.
Компилятор
Итак, у нас есть исходный текст, написанный на языке программирования. Он
Компилятор
Итак, у нас есть исходный текст, написанный на языке программирования. Он
Компилятор
Компилятор преобразует сразу весь исходный текст. На выходе, как правило, получается один или несколько файлов объектного кода. Будем считать, что объектный код - что-то вроде полуфабриката, который практически готов к употреблению процессором. В некоторых языках программирования, процесс компиляции может управляться так называемыми директивами компиляции - специальными указаниями о том, как компилировать отдельные блоки текста. В общей сложности, компиляция программы состоит из следующих этапов:
Лексический анализ. На этом этапе весь текст исходного файла преобразуется в последовательность лексем.
Синтаксический (грамматический) анализ. Последовательность лексем преобразуется в дерево разбора.
Семантический анализ. Дерево разбора обрабатывается с целью установления его смысла — например, привязка идентификаторов к их декларациям, типам, проверка совместимости, определение типов выражений и т. д. Результат обычно называется «промежуточным представлением».
Оптимизация. Выполняется удаление лишних конструкций и упрощение кода с сохранением его смысла. Оптимизация может быть на разных уровнях и этапах. Так же, оптимизация может заключаться в использовании группы команд более современного процессора.
Генерация кода. Из промежуточного представления порождается код на целевом языке.
Интерпретатор
Интерпретатор тоже преобразует текст на языке высокого уровня, но делает это
Интерпретатор
Интерпретатор тоже преобразует текст на языке высокого уровня, но делает это
Достоинства интерпретаторов:
Бо́льшая переносимость интерпретируемых программ — программа будет работать на любой платформе, на которой есть соответствующий интерпретатор.
Как правило, более совершенные и наглядные средства диагностики ошибок в исходных кодах.
Упрощение отладки исходных кодов программ.
Меньшие размеры кода по сравнению с машинным кодом, полученным после обычных компиляторов.
Недостатки интерпретаторов:
Интерпретируемая программа не может выполняться отдельно без программы-интерпретатора. Сам интерпретатор при этом может быть очень компактным.
Интерпретируемая программа выполняется медленнее, поскольку промежуточный анализ исходного кода и планирование его выполнения требуют дополнительного времени в сравнении с непосредственным исполнением машинного кода, в который мог бы быть скомпилирован исходный код.
Практически отсутствует оптимизация кода, что приводит к дополнительным потерям в скорости работы интерпретируемых программ.
Компоновщик
Компоновщик, известный так же как редактор связей, (linker, link editor) занимается
Компоновщик
Компоновщик, известный так же как редактор связей, (linker, link editor) занимается
Для связывания модулей компоновщик использует таблицы имён, созданные компилятором в каждом из объектных модулей. Такие имена могут быть двух типов:
Определённые или экспортируемые имена — функции и переменные, определённые в данном модуле и предоставляемые для использования другим модулям;
Неопределённые или импортируемые имена — функции и переменные, на которые ссылается модуль, но не определяет их внутри себя.
Работа компоновщика заключается в том, чтобы определить и связать ссылки на неопределённые имена в каждом модуле. Для каждого импортируемого имени находится его определение в других модулях и после этого упоминание имени заменяется на его адрес.
Отладчик
Отладчик или дебаггер является модулем среды разработки или отдельным приложением, предназначенным
Отладчик
Отладчик или дебаггер является модулем среды разработки или отдельным приложением, предназначенным
Список отладчиков:
1) AQtime — коммерческий отладчик для приложений, созданных для .NET Framework версии 1.0, 1.1, 2.0, 3.0, 3.5 (включая ASP.NET приложения), а также для Windows 32- и 64-битных приложений.
2) DTrace — фреймворк динамической трассировки для Solaris, OpenSolaris, FreeBSD, Mac OS X и QNX.
3) Electric Fence — отладчик памяти.
4) GNU Debugger (GDB) — отладчик программ от проекта GNU.
5) IDA — мощный дизассемблер и низкоуровневый отладчик для операционных систем семейства Windows и Linux.
6) Microsoft Visual Studio — среда разработки программного обеспечения, включающая средства отладки от корпорации Microsoft.
7) OllyDbg — бесплатный низкоуровневый отладчик для операционных систем семейства Windows.
8) SoftICE — низкоуровневый отладчик для операционных систем семейства Windows.
9) Sun Studio — среда разработки программного обеспечения, включающая отладчик dbx для ОС Solaris и Linux, от корпорации Sun Microsystems.
10) Dr. Watson — стандартный отладчик Windows, позволяет создавать дампы памяти.
11) TotalView — один из коммерческих отладчиков для UNIX.
12) WinDbg — бесплатный отладчик от корпорации Microsoft.
Генератор документации
Генератор документации — программа или пакет программ, позволяющая получать документацию,
Генератор документации
Генератор документации — программа или пакет программ, позволяющая получать документацию,
Обычно генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам и их членам/свойствам/методам, процедурам/функциям и т. п.). В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев. На основе всей собранной информации формируется готовая документация, как правило, в одном из общепринятых форматов — HTML, HTMLHelp, PDF, RTF и других.
Инструментальные средства разработки клиент-серверных приложений
Любое клиент-серверное приложение состоит из клиентского и
Инструментальные средства разработки клиент-серверных приложений
Любое клиент-серверное приложение состоит из клиентского и
Инструментальные средства для разработки клиентской части
Клиентской называется часть приложения, с которой
Инструментальные средства для разработки клиентской части
Клиентской называется часть приложения, с которой
Для того, чтобы воспользоваться многочисленными новейшими инструментальными средствами, предназначенными для создания клиентской части приложений, которые доступны сегодня на рынке программного обеспечения, разработчики должны уметь программировать на таких языках, как C++ и HTML, или на одном из множества других процедурных языков программирования, предназначенных для разработки Web-приложений. Раньше для разработки пользовательских корпоративных программ, работающих в основном в символьном режиме, использовались такие языки программирования, как ANSI С, COBOL, FORTRAN и Pascal. Сегодня большинство вновь разрабатываемых клиентских прикладных программ является GUI-приложениями - они содержат графический интерфейс пользователя. Большинство из доступных сегодня инструментальных средств являются дружественными по отношению к пользователю и объектно-ориентированными. Наиболее популярными средствами для создания Web-приложений являются C++-Builder и IntraBuilder фирмы Borland, а также Visual J++ и Visual C++ компании Microsoft. Другие популярные средства разработки корпоративных приложений для локальных вычислительных сетей - PowerBuilder компании Powersoft, Developer/2000 корпорации Oracle, Visual Basic компании Microsoft и Delphi фирмы Borland.