Какие факторы поменяли взгляд на разработку программного обеспечения
Обновлено: 30.06.2024
Разработка и использование компьютерных программ в настоящее время стали массовой деятельностью. Более семи миллионов человек занимаются их разработкой, а сотни миллионов активно их используют [1.1]. Практически нет ни одной сферы деятельности человека (экономика, медицина, бизнес, коммерция, промышленность и т. д.), где бы ПО не использовалось, как средство автоматизации и улучшения работ . Спрос на него постоянно увеличивается, сложность растет, а количество ошибок не уменьшается.
Знания разработчиков ПО отличаются разнообразием и, как правило, они являются неполными, несогласованными и разнородными, ориентированными на реализацию разных предметных областей, начиная от ОС и заканчивая прикладными бизнес-системами. И самое главное, знания в процессе инженерной деятельности постепенно уточняются, видоизменяются и пополняются, и их необходимо учитывать разработчикам нового ПО .
Примерно каждые 10 лет происходит смена языков программирования и операционных сред для описания и функционирования программ, что предполагает перевод ранее изготовленных и функционирующих программ на новые языки и операционные среды. На это тратятся огромные людские и финансовые ресурсы. Так, в 2000 году в изменении формата даты в программах и микросхемах на десятках млн. компьютеров участвовало более 2 миллионов программистов, а затраты составили сотни миллионов долларов. Перевод ранее созданных прикладных Фортран-программ на новые языки (С, Java и др.), и развертывание их в новых операционных средах требует больших капиталовложений и привлечения огромной армии программистов.
В связи с постоянным обновлением персональных компьютеров, соответственно, операционных сред и систем программирования, возникают сложности, связанные с адаптацией действующих программ и прикладных систем к новым условиям. В практике программирования не раз делались попытки облегчить труд по написанию программ, перейдя к "программированию без программистов". В связи с этим появлялись программные проекты, которые ставили своей целью заменить постановки задач математическим описанием и заставить машины их обрабатывать. К ним относятся компьютеризация математических знаний (машины серии "Мир", японский проект "ЭВМ 5-го поколения" [1.2]), фабрики программ по изготовлению программной продукции по типу сборочного конвейера из готовых "деталей"-программ (завод для сборки АСУ , система АПРОП, ПРИЗ) и многие другие проектные решения, направленные на изменение стилей программирования. Например, формальные спецификации и математическое доказательство правильности программ (1980 г.), систематизация знаний в области инженерии программного обеспечения и создание общего ядра знаний SWEBOK (2001, 2003гг.), теория построения и верификации программ (проект 2005 г.) и др.
Переворот в программировании по высвобождению армии пользователей компьютеров от разработки и написания программ так и не произошел, наоборот, методы и средства программирования постоянно развиваются. Особенно это связано с новыми возможностями платформ и распределенных сред, в которых компоненты располагаются по разным узлам сети и взаимодействуют между собой через сетевые протоколы. Кроме того, появились новые методы и подходы к разработке ПО : структурный, объектно-ориентированный, компонентный, аспектный, визуальный, агентно-ориентированный, сервисный и др. [1.3-1.12].
Для поддержки новых методов разработано огромное количество разнообразных инструментальных средств и методов оценки качества, производительности, стоимости и т.п. Процесс разработки ПО и методы оценивания продуктов стандартизованы (ISO/IEC 12207, 15504, 9126 и др.) [1.14, 1.16]. Все это способствует повышению эффективности проектирования, тестирования, прогнозирования надежности и оценки качества ПО .
Новый программный проект разрабатывается 1-2 года, а эволюционирует 6-7 лет. На сопровождение проекта тратится 61% против 39% средств на его разработку. Эффективность разработчиков в зависимости от квалификации колеблется в отношении 1:10, а значит, требуется повышать уровень знаний разработчиков ПО . На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех знаний, которыми пользуются в практической деятельности. В связи с этим проведена систематизация накопленных знаний в программировании и ряде других областей информатики. Международным комитетом при американском объединении компьютерных специалистов ACM ( Association for Computing Machinery ) и институте инженеров по электронике и электротехнике IEEE Computer Society было создано ядро знаний SWEBOK. В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления, сформулировано понятие программной инженерии и десяти областей, которые соответствуют процессам проектирования ПО и методам их поддержки.
Программная инженерия (Software Engineering) является отраслью информатики, которая изучает вопросы построения компьютерных программ, отражает закономерности развития программирования, обобщает опыт программирования в виде комплекса знаний и правил регламентации инженерной деятельности разработчиков ПО .
В этом определении выделим два основных аспекта.
- Программную инженерию можно рассматривать как инженерную дисциплину, в которой инженеры применяют теоретические идеи, методы и средства при разработке ПО, создают продукты в соответствии со стандартами, регламентирующими процессы их проектирования и разработки.
- Программная инженерия описывает методы управления программным проектом, качеством и рисками. Применение таких методов позволяет достичь высокого качества программных продуктов. Эта инженерная дисциплина предоставляет всю необходимую информацию и стандарты для выбора наиболее подходящего метода и процессов жизненного цикла ПО для реализации конкретного проекта.
Как инженерная дисциплина, она охватывает все аспекты создания ПО , начиная от формирования требований до создания сопровождения и снятия с эксплуатации ПО , а также включает инженерные методы оценки трудозатрат, стоимости, производительности и качества. Т.е. речь идет именно об инженерной деятельности в программировании, поскольку ее сущность близка к определению инженерной деятельности в толковом словаре:
инженерия - это способ применения научных результатов, что позволяет получать пользу от свойств материалов и источников энергии;
инженерия - деятельность по созданию машин для предоставления полезных для потребителя услуг и изделий.
Инженеры в программной инженерии - это специалисты, выполняющие практические работы по реализации программ с применением теории, методов и средств компьютерной науки. Компьютерная наука охватывает теорию и методы построения вычислительных и программных систем, тогда как программная инженерия рассматривает вопросы практического построения ПО . Знание компьютерной науки необходимо специалистам в области программного обеспечения так же, как знание физики - инженерам-электронщикам. Если для решения конкретных задач программирования не существует подходящих методов или теории, инженеры применяют свои знания, накопленные ими в процессе разработок конкретных ПО , а также используют опыт применения соответствующих инструментальных программных средств.
Инженеры, как правило, работают в условиях заключенных контрактов и выполняют задачи проекта с учетом этих условий и ограничений на сроки, время, стоимость и др. В отличие от науки, цель которой - получение знаний, для инженерии знание - это способ получения некоторой пользы. Кроме программистов, занимающихся непосредственно разработкой ПО , в программной инженерии используются:
- менеджеры, которые планируют и руководят проектом, отслеживают сроки и затраты;
- инженеры службы ведения библиотек и репозитариев компонентов;
- технологи, которые определяют инженерные методы и стандарты, создают для проекта модель ЖЦ, удовлетворяющую его целям и задачам;
- тестировщики (контролеры), которые проверяют правильность выполнения процесса проектирования путем тестирования и на основе собранных данных проводят измерения разных характеристик качества, включая оценку надежности ПО;
- верификаторы, которые проверяют правильность реализации функций в проекте;
- валидаторы, проверяющие ПО на соответствие заданным требованиям.
Разработку программных систем можно считать инженерной деятельностью, но она имеет некоторые отличия от традиционной инженерии:
- ветви инженерии имеют высокую степень специализации, а в программной инженерии специализация коснулась только отдельных областей (например, операционные системы, трансляторы, редакторы и т.п.);
- программирование объектов основывается на стандартах, с помощью которых отражаются типовые требования заказчиков, т.е. типизация объектов и артефактов в сфере программирования;
- технические решения классифицированы и каталогизированы, а в программной инженерии каждая новая разработка - это новая проблема, для реализации которой устанавливают аналогию с ранее разработанными системами. Одним из инженерных решений каталогизации в программировании является паттерн проектирования.
Для превращения программной инженерии в специальность мировая компьютерная общественность создала профессиональные комитеты, регламентирующие аспекты процесса программирования: ядро знаний SWEBOK, этический кодекс программиста [1.13], учебные курсы (Curricula -2001, 2004) по подготовке специалистов в области программной инженерии, обучение специальности и сертификация специалистов.
Таким образом, возникновение программной инженерии как дисциплины разработки ПО определено следующими важными факторами:
- значительным объемом накопленных знаний в области создания ПО;
- появлением новых методов анализа, моделирования и проектирования ПО;
- совершенствованием методов обнаружения ошибок в ПО;
- эффективной организацией коллективов разработчиков ПО и оценки их трудовой деятельности;
- использованием готовых программных компонентов, высокотехнологических средств и инструментов разработки ПО;
- необходимостью эволюционного развития компонентов и систем, а также их адаптацией к новым изменяющимся условиям операционных сред и компьютерных сетей.
Программная инженерия делает акцент на повышении качества и производительности ПО за счет применения: новых и усовершенствованных методов проектирования ПО ; готовых компонентов и методов их генерации; методов эволюции, верификации и тестирования ПО ; инструментальных средств; методов управления проектами, оценки качества и стоимости.
Ежедневно в мире производятся сотни новых программ, приложений, систем, либо очередных модификаций версий существующих программных средств. Даже специалисту в этой области сложно разобраться в таком множестве программного обеспечения. Особенно остро эта задача стоит при выборе того или иного программного продукта для новой информационной системы. Одной из сторон проблемы выбора является учет перспектив развития выбранного программного средства, которые во многом определяются общими тенденциями развития программного обеспечения. Знание перспектив развития в области программных средств позволяет пользователю более обоснованно выбрать то или иное приложение или систему.
Содержание
1. Введение 2
2. Перспективы развития программного обеспечения средств вычислительной техники 2
2.1. Основные понятия в программном обеспечении 2
2.2. Факторы, влияющие на развитие ПО 3
2.3.Основные тенденции развития программного обеспечения 8
2.4. Направления развития Microsoft 10
3. Заключение 11
4. Список использованной литературы 11
Прикрепленные файлы: 1 файл
Реферат 123.doc
2. Перспективы развития программного обеспечения средств вычислительной техники 2
2.1. Основные понятия в программном обеспечении 2
2.2. Факторы, влияющие на развитие ПО 3
2.3.Основные тенденции развития программного обеспечения 8
2.4. Направления развития Microsoft 10
3. Заключение 11
4. Список использованной литературы 11
Ежедневно в мире производятся сотни новых программ, приложений, систем, либо очередных модификаций версий существующих программных средств. Даже специалисту в этой области сложно разобраться в таком множестве программного обеспечения. Особенно остро эта задача стоит при выборе того или иного программного продукта для новой информационной системы. Одной из сторон проблемы выбора является учет перспектив развития выбранного программного средства, которые во многом определяются общими тенденциями развития программного обеспечения. Знание перспектив развития в области программных средств позволяет пользователю более обоснованно выбрать то или иное приложение или систему.
2. Перспективы развития программного обеспечения средств вычислительной техники.
2.1. Основные понятия в программном обеспечении.
Различают три вида программного обеспечения (ПО): системное, прикладное и инструментальное. К системному ПО относятся операционные системы (ОС), обеспечивающие эффективное использование аппаратно-программных ресурсов ЭВМ и предоставление пользователю необходимого интерфейса для работы на компьютере. Современные ОС, как правило, являются сетевыми.
Прикладное программное обеспечение делится на универсальное и специализир ованное. К универсальному ПО относятся офисные системы, системы управления базами данных и системы искусственного интеллекта.
Офисная система — совокупность приложений, обеспечивающих автоматизацию т ипичных функций организационного управления деятельностью офиса. Наиболее часто используемым приложением офисной системы являются текстовый и табличный процессоры. В офисной системе MS Office это соответственно MS Word и MS Excel.
Данные, требующиеся для решения задач пользователя, структурируются и накапливаются в базах данных (БД). Структуру данных в БД для представления той или иной предметной области определяет модель данных. Выделяют четыре основных типа моделей данных: иерархическую, сетевую, реляционную и объектную. Для задачи создания, пополнения, модификации и поиска данных в БД используют систему управления базой данных (СУБД). При работе с БД в среде некоторой СУБД различают три уровня представления данных: концептуальный, внешний и внутренний. Пользователь работает с данными в среде СУБД на внешнем уровне представления данных. Наиболее важная из функций СУБД — предоставление в распоряжение пользователя языка запросов, посредством которого он выражает свои информационные потребности.
Перспективным направлением является искусственный интеллект (ИИ) как совокупность средств и методов решения интеллектуальных задач на основе моделирования процессов выявления, представления и манипулирования знаниями с использованием средств вычислительной техники.
Для автоматизации процессов разработки программного обеспечения предназначены инструментальные системы, к которым относятся системы программирования и CASE-системы (программная инженерия).
2.2. Факторы, влияющие на развитие ПО.
Перспективы развития ПО определяются множеством факторов. Остановимся подробнее на некоторых из них.
- Развитие сети Интернет. К концу 2012 г. число пользователей Интернет по всему миру достигало 2,4 миллиарда пользователей по всему миру. К 2020 г. по прогнозам Национального Научного Фонда США число пользователей Интернет возрастет до 5 млрд. Интернет станет завоевывать практически все страны. Самый большой прирост пользователей в ближайшие 10 лет будет происходить за счет жителей развивающихся стран. Этот означает, что Интернет к 2020 году не только достигнет отдаленных мест по всему миру, но и будет поддерживать гораздо больше языков. Российских пользователей Интернет по данным Минкомсвязи РФ на начало 2012 года было 70 млн. чел. По этому показателю Россия вышла на первое место в Европе и на шестое место в мире. Согласно результатам исследования агентства РБК, уровень проникновения Интернета в России в 2018 году превысит отметку в 80%.
- ХХI век – это век беспроводных технологий. Только за 2009 г. число абонентов мобильной широкополосной связи (3G, WiMAX и другие технологии высокоскоростной передачи данных) увеличилось на 85 %. К 2015 г. прогнозируют, что 2,7 млрд людей по всему миру будут использовать мобильный широкополосный доступ.
- Новые объекты передачи. Благодаря развитию новых технологий можно будет передавать через компьютерные сети то, что раньше казалось невозможным. Например – запах. Машина анализирует молекулярный состав воздуха в одной точке и передает эти данные по сети. В другой точке сети этот молекулярный состав, т.е. запах - синтезируется. Прототип подобного устройства уже выпустила американская компания Mint Foundry, называется она Olly.
“Мы подготовили для вас перевод статьи о методологиях разработки, которая в сжатой форме описывает наиболее популярные из тех, что используются сегодня. Хотя эти методологии в большей степени относятся именно к разработке программного обеспечения, мы SMART business также очень широко используем их для внедрения систем по управлению бизнесом.
В этих внедрениях главной частью является не разработка программного обеспечения, а конфигурирование и поднастройка к существующим в компании бизнес-процессам, путем использования того набора инструментов и функциональности, который уже создан поставщиками таких решений. С каждой версией эти инструменты совершенствуются, и трудно не заметить фокус на абсолютно новую аудиторию – Citizen Developers. Наверное, вы все видите, какую популярность набирают no-code и low-code подходы, роботизация процессов (RPA), и самое интересное то, что новые инструменты требуют новых подходов.
Хотим поделиться с вами последними обновлениями методологии Microsoft, получившей название Success by Design, и очень рекомендуем всем, кто интересуется этим вопросом, ознакомиться с бесплатным курсом, поскольку он, по нашему мнению, относится не только к Microsoft Dynamics 365 и Power Platform, но и очень структурировано описывает подход к решению бизнес-задач с цифровизации компаний.”
Кирилл Руднев управляющий партнер SMART business
Сегодня мы живем в мире, где весь контроль – под рукой. Технологии развиваются за гранью воображения. И все благодаря индустрии разработки программного обеспечения!
Методология, предназначенная для жизненного цикла разработки ПО, фактически является структурой, используемой для планирования и управления процедурой создания специализированной информационной системы для достижения желаемых целей.
Эти инновационные методы подчеркивают процесс создания программного обеспечения на каждом этапе разработки. Фактически, это постепенное развитие больше связано с управлением проектами и как таковое не предполагает каких-либо технических нюансов.
Это скорее касается правильного планирования и включает в себя любые итерации, необходимые для создания высокомасштабируемого программного обеспечения.
Простота и надежность этих принципов заключается в том, чтобы предлагать индивидуальную разработку ПО в соответствии с требованиями, и это то, что должна принять каждая команда разработчиков ПО.
Каскадная модель (“Waterfall”)
Если вы работаете в компании по разработке программного обеспечения, в какой-то момент вы непременно сталкиваетесь с каскадной моделью ведения проекта по разработке продукта.
Рассматриваемый как традиционный метод разработки ПО в программной инженерии, каскадный метод позволяет представить процесс в виде линейного потока с заданной последовательностью, чтобы пользователи понимали, что следующий этап наступает по завершении предыдущего. Более того, согласно этой методологии, вернуться к исправлению изменений невозможно.
Плюсы:
- Легкая для понимания и функциональная.
- Достаточно проста в обращении благодаря зафиксированной структуре.
- Экономит много времени.
- Позволяет легко тестировать и анализировать.
Минусы:
- Соответствует только конкретным потребностям.
- Не применима к проектам технического обслуживания.
- Нет возможности узнать возможный результат проекта.
- Не подходит для длительных и бессрочных проектов.
Прототипирование
Это специализированный принцип разработки программного обеспечения, согласно которому разработчики создают только образец решения, чтобы подтвердить его функциональную суть для клиентов и провести существенную итерацию перед созданием конечного продукта и финальным тестированием качества.
Лучшее в этой методологии то, что она обычно помогает решить ряд разнообразных проблем, возникающих при использовании каскадного метода.
Плюсы:
- Дает четкое представление о функциональном процессе программного обеспечения.
- Снижает риск сбоя в работе программного обеспечения.
- Хорошо помогает при сборе требований и общем анализе.
Минусы:
- Вероятность увеличения управленческих расходов.
- Чрезмерное участие клиента может повлиять на работу.
- Слишком много изменений, влияющих на рабочий процесс по разработке программного обеспечения.
Методология гибкой разработки ПО (“Agile”)
Как инновационный подход и одна из ведущих моделей разработки ПО, методология гибкой разработки программного обеспечения используется для формулирования хорошо организованной процедуры управления проектами, допускающей периодические изменения.
Безусловно, методология Agile-разработки – это теоретический план для реализации нескольких программных продуктов и проектов.
Плюсы:
- Agile-подход адаптивен и благоприятно реагирует на изменения.
- Позволяет прямое общение для поддержания прозрачности.
- Постоянное улучшение качества за счет быстрого обнаружения и устранения дефектов и раннего выявления несоответствий ожиданиям.
Минусы:
- Методология сосредоточена на работе с программным обеспечением, а не на эффективном документировании.
- Есть шансы сбиться с пути, поскольку исход не ясен.
Быстрая разработка приложений
(RAD – Rapid Application Development)
Быстрая разработка приложений, нацеленная на получение быстрых результатов, представляет собой модель разработки программного обеспечения, которая может помочь создать превосходные процессы с помощью других подходов к разработке ПО.
Подход создан, чтобы максимально использовать преимущества ПО для разработки.
Он предназначен для увеличения работоспособности всего проекта по разработке ПО и акцентирует участие активного пользователя.
Найм сотрудников для таких проектов непрост, потому что необходимо учитывать множество факторов. В этой статье Collectiveray речь идет о нескольких способах поиска разработчиков приложений для таких проектов.
Плюсы:
- Упрощает весь процесс разработки.
- Помогает клиенту совершать быстрые проверки.
- Поощряет обратную связь от клиентов для улучшения.
Минусы:
- Производительность зависит от команды.
- Работает на модульной системе, ограниченной этой методологией.
- Требуется высококвалифицированный персонал для решения сложных задач.
- Не применим для проектов с небольшим бюджетом.
Метод разработки динамических систем
(DSDM – Dynamic System Development Model)
Аутентично сформулированный и созданный на основе методологии быстрой разработки приложений, этот итеративный и поэтапный подход ориентирован на участие пользователя.
Задача этой методологии – обеспечить рабочий процесс разработки ПО в рамках конкретных сроков и выделенного бюджета.
Именно поэтому он достаточно востребован в мире разработки программного обеспечения.
Плюсы:
- Пользователи получают контроль над процессом разработки ПО.
- Функциональность разрабатывается быстро.
- Легкий доступ разработчиков к конечным пользователям.
Минусы:
- Внедрение этой методологии требует больших затрат.
- Не подходит для небольших организаций.
Спиральная модель
Имея сложную структуру, этот подход призван снизить ранние риски в проекте.
Что касается процесса разработки ПО, разработчики начинают на низких уровнях и исследуют присущие ему риски.
Далее разработчики создают план итераций по спирали. Реализация любой модели жизненного цикла спирали основывается на последовательном, внимательном и грамотном управлении проектом.
Плюсы:
- Факторы риска значительно снижены.
- Отлично подходит для больших и сложных проектов.
- Позволяет создавать дополнительные функции позже.
- Подходит для очень рискованных проектов с различными бизнес-потребностями.
Минусы:
- Дорогостоящая модель в разработке ПО.
- Сбой на этапе анализа рисков может нанести ущерб всему проекту.
- Не подходит для проектов с низким уровнем риска.
- Может затянуться и никогда не закончиться
Экстремальное программирование (XP)
Экстремальное программирование определяется тем фактом, что вовлеченность клиентов в процесс создания ПО невероятно высока.
Как методология гибкой разработки ПО, методология экстремального программирования в настоящее время известна как методология XP.
Он в основном используется для создания ПО в очень несбалансированной атмосфере.
Это обеспечивает большую управляемость в рамках процедуры моделирования.
Основная цель модели XP – снизить стоимость необходимого программного обеспечения.
Однако в рамках модели XP цена изменения требований на последующих этапах проекта может быть огромной.
Плюсы:
- Основное внимание уделяется вовлечению клиентов.
- Устанавливает рациональные планы и графики.
- Разработчики очень преданны проекту.
- Использование современных методов качественного программного обеспечения.
Минусы:
- Эффективность зависит от вовлеченных людей.
- Требуются частые встречи по разработке, что увеличивает общие затраты.
- Необходимость чрезмерных изменений в разработке.
- Будущие возможности и результаты точно не известны.
Рассмотрим некоторые дополнительные преимущества, которые вы можете получить при использовании XP:
Коммуникация
В XP процесс коммуникации прост, надежен и довольно прозрачен. Каждый из членов команды зависит друг от друга и делится знаниями внутри команды, что означает, что все знают об обязанностях друг друга.
Простота
Поскольку сам этап коммуникации начинается с простого и прозрачного подхода, простота гарантируется на всех остальных этапах. Более того, в этом контексте простота относится к реализации подхода, при котором вы сокращаете всё неважное и включаете только необходимую информацию.
Обратная связь
Благодаря обратной связи легче отследить области, которые можно улучшить наряду с модификацией применяемых в ней процессов, чтобы обеспечить качество продукции.
Мотивация
Смелость – это не что иное, как набор действий, которые в случае их реализации могут нанести вред команде и бизнес-требованиям. С мотивацией вы можете работать над выявлением серьезных факторов, которые могут повлиять на ваши услуги.
В команду, работающую по методологии Экстремального программирования, входит 5 человек: клиент, координатор, программист, специалист по контролю качества и трекер.
Разработка, управляемая функциональностью
(FDD – Feature-driven development)
Являясь итеративной методологией разработки программного обеспечения, она нацелена на обслуживание большого количества команд, работающих над проектом на основе объектно-ориентированной технологии. Такая модель подходит для компаний, которые переходят от поэтапного метода к итерационному.
Она известна как методология FDD и достаточно функциональна и креативна, чтобы справляться с различными сложностями.
Плюсы:
Минусы:
- Не подходит для небольших проектов и одного разработчика – всегда требуется огромная команда, а это означает, что невозможно гарантировать быстрый релиз в срок.
- Высокая степень зависимости от ведущих разработчиков, что требует полной структуры – процесс необходимо контролировать на каждом этапе, поскольку даже незначительный недостаток может создать хаос в системе.
Совместная разработка приложений
(JAD – Joint Application Development)
Методология совместной разработки приложений – это подход к классификации требований и расширению пользовательского интерфейса, который требует от конечных пользователей, клиентов и разработчиков присутствия на крупной удаленной конференции, где они могут расставить акценты и согласовать программную систему.
Эта методология служит для включения клиента в разработку и расширение приложения.
Подход реализуется с помощью серии согласованных семинаров, известных как JAD-сессии.
Он, как правило, ставит во главу угла сложности бизнеса, а не методические детали.
Плюсы:
- Позволяет одновременно собирать и объединять большие объёмы информации.
- Генерирует огромное количество ценной информации за короткий период.
- Позволяет немедленно решать разногласия с соответствующей помощью.
- Предоставляет форум для рассмотрения разных вопросов.
Минусы:
- Планирование и составление расписания отнимает много времени.
- Требует значительных затрат времени и усилий.
- Требует высококвалифицированных специалистов, которых сложно найти.
Бережливая разработка ПО (Lean Development)
Как следствие технического прогресса, модель бережливой разработки делает упор на создание легко управляемого программного обеспечения.
Эта тонко разработанная методология более продумана, чем любая другая форма гибкой методологии.
Цель этой процедуры – улучшить ПО в три раза быстрее, при очень ограниченном бюджете и минимальном объеме необходимого рабочего процесса.
Плюсы:
- Меньше требований к бюджету и времени.
- Позволяет предоставить продукт раньше срока.
Минусы:
- Работоспособность команды определяет успех процесса разработки ПО.
- Неподходящий бизнес-аналитик может стать причиной серьезных проблем.
- Излишняя гибкость приводит к тому, что разработчик теряет фокус.
Rational Unified Process (RUP)
Методология Rational Unified Process, получившая название RUP, обеспечивает разработку программного обеспечения с использованием Rational Tools.
Эта методология разделяет процесс расширения на четыре различных этапа, каждый из которых включает бизнес-моделирование, проверку и проектирование, внедрение, тестирование и утилизацию.
Это объектно-ориентированная методология развития программ в режиме онлайн.
Модель помогает разработчикам программного обеспечения в формулировании руководящих принципов, шаблонов и образцов для всех функций и этапов разработки программного обеспечения.
Плюсы:
- Особое внимание уделяется точной документации.
- Устраняет риски, связанные с меняющимися потребностями клиентов.
- Мало требований по интеграции.
Минусы:
- Требуется очень опытный разработчик ПО.
- Сложная процедура разработки методологии.
- Интеграция может вызвать путаницу.
- Очень сложна для понимания.
Scrum
SCRUM – это наиболее предпочтительный подход к гибкой разработке для большинства команд разработчиков ПО, который фактически является гибкой средой. (Аналогично, KANBAN – это процесс, который помогает командам сотрудничать и эффективно работать.) По сути, эта методология подходит для программных проектов, которые постоянно меняются или имеют чрезвычайно высокие требования к масштабированию.
Модель разработки программного обеспечения Scrum начинается с непродолжительного планирования, конференции и завершается заключительным обзором.
Эта методология используется для создания ПО и включает в себя серию итераций для создания необходимого программного обеспечения.
Это идеальный подход, потому что он без особых усилий приводит в движение прогрессирующие проекты.
Плюсы:
- Принятие решений находится в руках команды.
- Документ бизнес-требований считается несущественным.
- Малоконтролируемый метод, предполагающий постоянные обновления.
Минусы:
- Нестабильная стоимость.
- Не подходит для крупных проектов.
- Требуется высококвалифицированная команда, в которой нет места новичкам.
Технологии проложили путь ко многим радикальным изменениям в разработке программного обеспечения, которые даже изменили подходы к программированию.
Главное – то, что они решают самые разные сложности, требующие квалифицированного подхода.
Для разработки ПО существуют методологии, которые работают на определенных платформах, что дает им свободу действий.
Это требует высокого качества работы под руководством профессионалов, имеющих многолетний опыт эффективного решения технических проблем.
Благодаря различным формам методологий, применимых к разному набору проектов разработки программного обеспечения, у разработчиков есть множество вариантов для создания превосходно работающего ПО.
Сегодня все смотрят именно в сторону технологий, и постоянные изменения привели к разработке различных программных продуктов. И именно методологии создания полезного программного обеспечения улучшают бизнес-процедуры и предоставляют возможности для создания технических методологий.
Существенным фактором разработки качественного программного обеспечения является то, что оно упрощает сложную процедуру, но требует комплексного подхода к техническим деталям и экспертных знаний.
Именно гибкие команды и эксперты помогают каждому программному продукту работать эффективно; в противном случае весь процесс может быть испорчен.
В процессе разработки программного продукта важно соблюдать ряд требований, чтобы обеспечить качество программы.Но что конкретно, представляет собой качество программы? Ведь “качество”, можно понимать по разному.
Давайте рассмотрим вместе с вами, что представляет собой обеспечение и контроль качества программного обеспечения.
Обеспечение качества - включает в себя список характеристик и свойств программы, которые должны соблюдаться во время разработки программы и выполняться при ее работе. Обеспечение качества производится на всех этапах развития программного обеспечения: от начала разработки, до выпуска программы в пользование.
Контроль качества - означает проверку выполнения требований к программному обеспечению и общую оценку разработки. Основная задача контроля качества - поиск ошибок в программе и их дальнейшее исправление.
Обеспечение контроля и качества программного обеспечения определяется в соответствии с различными требованиями в зависимости от особенностей проекта. Основными требованиями, часто определяемыми для любой программы, являются:
- Функциональность - включает в себя набор действий, которые решают задачи пользователя. Набор этих действий описан в функциональных требованиях к программному обеспечению.
- Надежность - определяет требование при котором программа должна выполнять свои задачи в определенных условиях и заданное количество времени. Программа должна не только корректно работать, но и корректно завершать свою работу, без влияния на сохранность пользовательских данных.
- Мобильность - определяет возможность использовать программу на другом аппаратном обеспечении, либо совместно с другими программами.
- Эффективность - определяет степень производительности программы с выделенными для нее ресурсами операционной системы.
- Удобство использования - означает простое и легкое использование программы и ее компонентов для пользователя.
- Сопровождение - это требования к процессу улучшения программы, исправления ошибок, добавления нового функционала.
Обеспечение качества программного обеспечения достигается за счет создания определенных процессов.
Стандарты к разработке программного обеспечения
Определите общий шаблон стандартов к разработке программного обеспечения. Возьмите за основу готовые стандарты, либо проработайте свои и предложите разработчикам строго придерживаться их.
Отсутствие каких-либо общепринятых стандартов способен усложнить процесс разработки и сопровождения программы в дальнейшем. Принятие стандарта сделает процесс разработки и тестирования программы более качественным. Придерживаясь общему шаблону с перечнем принятых требований к разработке, программисты допускают меньше ошибок. Однако при этом, стандарт не должен накладывать ограничения на разработку, если это не противоречит качеству программы.
Инструкции с последовательными действиями
Если вы уже используете свой список процессов разработки, то стоит убедиться, что все они действительно подходят и позволяют достичь качества программы. В ином случае, нужно проработать процессы, которые позволяли бы наиболее эффективно взаимодействовать команды разработчиков с тестировщиками, обеспечить применение подходящих инструментов и стандартов.
Опыт предыдущих проектов
В обеспечении качества программы важную роль может сыграть опыт и ошибки предыдущих проектов. На основе этого можно принять решения о том, какие действия позволяют улучшить качество в текущем проекте, а какие нет. Поэтому необходимо обращать внимание на результат проделанной работы, чтобы можно было изучить полученный опыт и сделать выводы.
Предыдущие ошибки
Улучшение подходов в разработке и тестированию
Постоянно улучшайте процессы и методики разработки программного обеспечения. Изучите все стороны используемых процессов и выберите наиболее оптимальный вариант для будущих проектов.
В заключение
Помните, что в обеспечение качества программы, входит не улучшение тестирования, а улучшение всех процессов разработки и выпуска программы.
Если программа соответствует потребностям пользователей и ожиданиям разработчиков, то можно сказать, что программа успешно прошла оценку качества и готова к выпуску.
Автор
Программист с образованием в области IT и опытом разработки на разных языках. Автор статей по программированию. Общий опыт работы в сфере IT и интернета более 5 лет.
Рекомендуем вам ознакомиться с первой частью данной статьи, если вы не сделали этого ранее. Вам будет в два раза интереснее и в восемь раз понятнее.
1. Алгоритмическая сложность
Как алгоритмическая сложность влияет на разработку? Во-первых мы имеем многообразие структур данных и алгоритмов. Всевозможные стеки, деки, деревья, В-деревья, хеш-таблицы — все это разные способы представления информации. И выбор разработчик делает в зависимости от того, какие операции в данном случае чаще будут использоваться, соответственно, он обязан в этих структурах данных ориентироваться, как рыба в воде.
2. Трудоемкость разработки
Кроме того, чтобы поддерживать производительность на одном уровне, есть определенные правила, называемые SOLID-принципы. Если их придерживаться, то все-таки можно добиться того, что скорость работы на проекте не будет катастрофически падать. Единственная проблема как раз состоит в том, чтобы выдержать следование этим правилам. Их всего пять и это, определенно, отдельная тема для разговора в рамках объектно-ориентированного программирования.
3. Информационная сложность
Она же — Колмогоровская сложность. Это понятие ввел в 1939 году известный советский математик Андрей Николаевич Колмогоров. Коротко ее можно описать следующим образом: информационная сложность задачи/объекта определяется количеством символов, которые необходимо записать, чтобы эту задачу решить.
То есть, фактически, сложность задачи равна количеству символов, описывающих ее решение.
Что это значит для программистов? Это, по сути, размер программы, которую они напишут для решения задачи. Понятно, что все стремятся использовать различные обозначения и приемы, чтобы уменьшить количество символов. Отсюда возникает идея, что и эту сложность можно уменьшать. Но на самом деле все обстоит так: доказано, что определить информационную сложность задачи — это алгоритмически неразрешимая проблема. То есть, для компьютера не существует такого алгоритма, который может нам сказать, какое минимальное количество символов необходимо для решения той или иной задачи. К чему это приводит?
Во-первых, невозможно оценивать, какого размера достигнут наши приложения.
Во-вторых, появляется все больше новых языков программирования. Возникают конструкции, которые призваны уменьшить количество символов в коде и сделать запись более компактной. И непонятно, когда этот процесс остановится: ведь мы не знаем, какое количество символов считать минимальным для описания какой-либо операции.
Еще одна идея состоит в том, что чем больше предметная область, для которой пишется программа, чем больше задача — тем больше вырастает ее информационная сложность. И процесс по созданию более компактных записей все равно не успевает за потребностями бизнеса.
Так и получается, что программы становятся все более и более громоздкими, а задачи обладают все большей информационной сложностью.
Тут самое время вспомнить о проблеме математиков: есть теория о том, что к 2075 году доказательства станут настолько большими и длинными, что одному человеку будет не под силу за всю жизнь понять даже одно из них. Фактически — возникнет потребность в помощи компьютера, который будет эти доказательства строить. По аналогии с математикой можно предположить, что скоро и программы станут настолько масштабными. Но предсказывать будущее с уверенностью мы не можем, поскольку вычислить их информационную сложность нельзя. Тем не менее, опять и опять возникает потребность в программах, которые будут писать за нас другие программы, а это и есть в нынешнем понимании машинное обучение. Но, как с математическими доказательствами, так и с написанием программ есть еще одна сложность — четвертая.
4. Сложность тестирования
Экскурс в историю
Читайте также: