Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном. Евгений Леонидович Шуремов
Чтение книги онлайн.
Читать онлайн книгу Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном - Евгений Леонидович Шуремов страница 5
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО.
Современные тенденции в программной инженерии
В начале 2001 года века ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance’s Manifesto) и заключающихся в следующем:
– индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;
– работающее ПО ценится выше всеобъемлющей документации;
– сотрудничество с заказчиками ценится выше формальных договоров;
– реагирование на изменения ценится выше строгого следования плану.
При таком подходе технология занимает в процессе создания ПО вполне определенное место и повышает эффективность деятельности разработчиков при наличии следующих условий:
– технология позволяет людям легче выразить свои мысли;
– технология выполняет задачи, невыполнимые вручную;
– технология автоматизирует утомительные и подверженные ошибкам действия;
– технология облегчает общение между людьми.
Технология не должна действовать против характера культурных ценностей и познавательной способности человека.
Однако при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО. Ее уровень может иметь одно из четырех значений:
– C – дефекты вызывают потерю удобства;
– D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
– E – дефекты вызывают потерю невозместимых средств;
– L – дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в проекте:
– от 1 до 6 человек – малый масштаб;
– от 6 до 20 человек – средний масштаб;
– свыше 20 человек – большой масштаб.
По оценке