Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном Страница 3
- Категория: Научные и научно-популярные книги / Прочая научная литература
- Автор: Евгений Шуремов
- Год выпуска: неизвестен
- ISBN: нет данных
- Издательство: -
- Страниц: 6
- Добавлено: 2019-01-29 13:15:07
Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном» бесплатно полную версию:Книга содержит краткое изложение основной проблематики, связанной с процессами промышленной разработки программного обеспечения информационных систем организационно-экономического управления. Рассматриваются основные существующие методологические подходы и методики организации разработки, а также наиболее популярные поддерживающие их инструментальные средства. Изложение ориентировано на минимально подготовленных читателей, желающих получить общее представление по данной теме.
Евгений Шуремов - Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном читать онлайн бесплатно
– недостаточное вовлечение пользователей в работу над проектом;
– отсутствие необходимых ресурсов;
– неудовлетворительное управление проектом;
– частое изменение требований и спецификаций;
– новизна и несовершенство используемой технологии;
– недостаточная поддержка со стороны высшего руководства;
– недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering). В основе программной инженерии лежит следующая фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.
В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области – неспособность эффективного управления проектами создания ПО.
Выяснилось, что невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно. Часто разработчики не обладают необходимой квалификацией для работы с ними, а сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания ПО (ТС ПО), в свою очередь, порождает разочарование в используемых методах и средствах. Анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков. Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации.
Одна из причин распространенности «хаотического» процесса создания ПО – стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой ТС ПО, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина – в сложности «тяжелых» технологических процессов, имеющих следующие особенности:
– необходимость документировать каждое действие разработчиков;
– множество рабочих продуктов (в первую очередь – документов), создаваемых в бюрократической атмосфере;
– отсутствие гибкости;
– детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности, а также распределение человеческих ресурсов на длительный срок, охватывающий большую часть проекта.
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО.
Современные тенденции в программной инженерии
В начале 2001 года века ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance’s Manifesto) и заключающихся в следующем:
– индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;
– работающее ПО ценится выше всеобъемлющей документации;
– сотрудничество с заказчиками ценится выше формальных договоров;
– реагирование на изменения ценится выше строгого следования плану.
При таком подходе технология занимает в процессе создания ПО вполне определенное место и повышает эффективность деятельности разработчиков при наличии следующих условий:
– технология позволяет людям легче выразить свои мысли;
– технология выполняет задачи, невыполнимые вручную;
– технология автоматизирует утомительные и подверженные ошибкам действия;
– технология облегчает общение между людьми.
Технология не должна действовать против характера культурных ценностей и познавательной способности человека.
Однако при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО. Ее уровень может иметь одно из четырех значений:
– C – дефекты вызывают потерю удобства;
– D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
– E – дефекты вызывают потерю невозместимых средств;
– L – дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в проекте:
– от 1 до 6 человек – малый масштаб;
– от 6 до 20 человек – средний масштаб;
– свыше 20 человек – большой масштаб.
По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:
– интерактивное общение лицом к лицу – это самый дешевый и быстрый способ обмена информацией;
– избыточная «тяжесть» технологии стоит дорого;
– более многочисленные команды требуют более «тяжелых» и формальных технологий;
– большая формальность подходит для проектов с большей критичностью;
– возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;
– дисциплина, умение и понимание противостоят процессу, формальности и документированию;
– потеря эффективности в некритических видах деятельности вполне допустима.
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming – XP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, что достигается посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению, навыкам, дисциплине, пониманию.
Однако задача поиска повторяемого, предсказуемого процесса или методологии, которые бы улучшили продуктивность, качество и надёжность разработки до сих пор не решена. Одни подходы делают акцент на систематизации и формализации процессов. Другие ставят во главу угла методы управления проектами и методы программной инженерии. Третьи исходят из необходимости постоянного контроля со стороны заказчика.
При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки.
Инструментальные средства бизнес-моделирования
Моделирование бизнес-процессов является важной составной частью проектов по созданию крупномасштабных систем ПО организационно-экономических систем. Отсутствие таких моделей является одной из главных причин неудач многих проектов.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.