Сложность по. Кризис разработки по
Сложность ПО.
Кризис разработки ПО.
Возник в конце 60тых годов, и был связан с тем, что знасительная часть проэктов о разработке ПО была не закончена в срок и не уложилась в отведенный бюджет. Это связанно с тем, что разработка ПО является промышленным процессом. ПО должно иметь долгий срок жизни и решать достаточно большой круг задач.
1. Сложность реальной предметной области, на которой исходит заказ на разработку.
2. Трудность управления процессом разработки.
3. Необходимость обеспечить достаточную гибкость программы.
4. Неудовлетворительными спообами описания оседания больших дискретных систем.
Причины обуславливающие сложность:
1. Не четкие требования со стороны заказчика.
2. Недостаточная заинтересованность со стороны вышестоящего руководства.
3. Несовершеннство используемых технологий.
4. Отсутствие квалифицированных разработчиков.
Признаки сложной системы.
Сложная система состоит из набора компонентов, организованных иерархически, и каждый из этих компонентов может быть разбит на подсистемы и так далее в плоть до самого низшего уровня.
Компоненты предсталяют из себя небольшой набор, разделяемый по типам.
Выбор компонента который будет являлся элементарным относителено произволен и остается на усмотрение разработчикам.
Внутрикомпонентая связь гораздо сильнее, чем связь между компонентами.
Любая сложная работающая система является развитием более простой работающей системой. Сложная система созданная с нуля, никогда работать не будет.
Пакетом прикладных программ называется ПО предназначение для решение определенного круга задач. Пакет прикладных программ с дружественным профессионально ориентированным интерфейсом пользователя, называется программной системой. Программная система обладающая качествами промышленного изделия называется промышленные программным продуктом.
(рассмотреть модели:XP, RUP, SCRUB).
V-образная модель разработки программного обеспечения.
ПРИЛОЖЕНИЕ:фото.
V- образная модель является дальнейшим развитием каскадной модели. Как и каскадная модель v-образная используется в тех случаях, когда требования к ПО четко определенны на начальном этапе. Основные отличия данной модели от каскадной является то, что каждый этап имеет связанный этап который позволяет проверить прааильность принятого решения.
Основными недостатками являются: то что выполнение проверки затруднено потому что требования выявленные на ранних этапах часто не соответствуют тому что было реализованно. Кроме того, если выполнение этапа не подтверждается, возврат на предыдущий связан с большими финансовыми и временными затратами. Подходит для проэктов с высоким уровнем критичности и большим масштабом.
Спиральная модель.
Спинальная модель является первоц из класса итеративной оделью. Основным отличием данной модели от каскадной по мимо итеративности, является то, что она ориентированна на риски. Под рисками понимаются факторы в результате действия которых программный проэкт может закончится неудачей. Риски могут включать:
не четкую формулировку задачи;
неизветную технологию;
плохо понятную архитектуру;
Спиральная модель декомпозирует проэкт сверху вниз, на риск ориентированные под проэкты. В начале каждого этапа анализирются дкловые и технические риски. Затем эти риски ранжируются по мере критичности, и первым выполняется подпроэкт, имеющий максимальные риски.
В конце каждого витка спирали анализируется проделанная работа и принимаются решения по правильности полученного результата. В случае соответствия резульата требования выполняется следующий подпроэкт, в противном случае - подпроэкт повторяется. За 6 витков спирали подпроэкт должен быть реализован. Основными преимущкствам данной модели является:
Разбиение проэкта на подпроэкты.
Анализ рисков на начальных этапах.
Получение прототипа после каждой итерации.
Недостатки:
Спиральная модель требует вдумчивого управления проэкта, это связанно с тем, что очень трудно определить требования проверки правильности выполненого подпроэкта, принять решение о переходе к следующей итерации.
Эволюционная модель.
Эволюционная модель разработки ПО предлогает разработку системной концепции программного продукта при движении через проэкт, тоесть на ранних этапах реализуются самые видимые аспекты системы которые воплощаются в ее прототип. затем прототип предьявляется заказчику и после его одобрения работа над проэктом продолжается. Таким образом разработка базируется на обратной связи с заказчиком. Процесс продолжается до тех пор, пока заказчик не одобрит полученный результат.
Недостатками являются:
Завуалированность технологии(отсутствие технологии);
Неопределено количество итераций(не известно сколько денег будет потрачено и не известны сроки);
Подходит для проэктов малого масштаба с не четко определенными требованиями.
Адаптивная модель разработки ПО.
Адаптивная модель используется в тех случаях, когда требования создаваемому программному продукту полностью не известны на начальных этапах разработки. Такая ситуация может возникнуть а том случае, когда решается абсолютно новая задача, смысл которой заключатся в проверке той или иной гипотезы. данный фактор отражен в 3х компонентах модели. Это компонент размышляйте(как бы деятельноть планирования), сотрудничайте(активное вовлмчение в проект всех заинтересованных сторон), учитесь(постоянный анализ полученных результатов и принятие решений на основе этого анализа).
Экстримальное программирование.
Автор: Кент Бэк.
Приниципы технологии экстримального программирования:
Игра планирования - быстрое определение области действияий следующей реализации путем определения деловых и технических приоритетов.
Частая смена версий. Новая версия появляется раз в две недели.
Метафора. Разработка ведется на основе простой общедоступной идее.
Простое проектирование. Проектирование выполняется на столько просто, на сколько это возможно.
Тестирование. Непрерывное написание тестов, которые должны демонстрировать не работоспособность систем, а выявлять ошибки. При этом, данные для тестов готовят заказчики.
Реорганизация(оптимизация). Система реконструируется, но ее цель не изменяется. Цель: оптимизаровать работу, добиться гибкости.
Парное программирование. Код каждой подсистемы пишется двумя программистами поочередно.
Коллективное владение кодом. Любой разработчик имеет возможность улучшать код в любое время.
Непрерывная интеграция. Система собирается и интегрируется по несколько раз в день.
Сорокачасовая рабочая неделя.
Локальный заказчик. Постоянное присутствие заказчика в коллективе разработчиков.
Стандарты кодирования. Правила как писать код. Должны ввдерживаться правила, обеспечивающие одинаковое построение кода.
Роли разработчиков.
Архитектор. Основной задачей архитектора является описание компонентов системы и процедуры взаимодействия этих компонентов. в не больших проектах(малый и средний масштаб) роль архитектора выполняется 1-2 сотрудниками-разработчиками. В крупных проектах это роль распределяется по коллективам. архитектор должен иметь глубокие знания в области средств проектирования и методологии программных комплексов. Наличие глубоких знаний и навыков кодирования не обязательно. Архитектор не являлся самым главным разработчиком, однако имеет возможность принимать стратегические решения по проектам.
Ответственные за подсистемы. Занимаются проектированием конкретных компонентов системы (совместно с архитектором) и процесс их реализации. должен иметь знания в области методологии и проектирования программных систем, и иметь глубокие навыки кодирования.
Прикладные программисты. Реализуют компоненты под руководством ответственного за подсистемы.
Дополнительные роли разработчиков.
Встречаются в крупных и средних проектах.
Менеджер проекта. Отвечает за управление организационными и финансовыми составляющим проекта.
Ответственный за интеграцию. Ответственный за интеграцию занимается сборкой версий системы.
Дизайнер.
Инструментарьщик. Следит что бы все использовали одинаковые версии компонентов сторонних организаций. Так же следит, чтобы были использованы одинаковые версии, разработанные другими программистами.
Инженер по повторному использованию. анализируется наработанное в текущем проекте, анализирует ранне выполненные проекты, ищет похожие места в проектах, выделяет компоненты которые можно использовать повторно и адаптирует их для повторного исользования.
Инженер о качеству.
Ответтвенный за документацию(технический писатель).
Системный администратор.
Методология SCRUM.
СМОТРЕТЬ ПРЕЗЕНТАЦИЮ.
Scrum мастер - создает атмосферу доверия, учавствует в митингах в качестве фасилитатора, устраняет препятствия, отвечает за соблюдение практик и процесса в команде.
Product owner - отвечает за архитектуру, управлять ROI, управляет ожиданиями заказчиков, взаимодействует с командой и заказчиком, ставит задачи в команде.
Команда - 7 +- 2. Отвечает за оценку элементов баклога, и др.
Product backlog.
Техническое задание.
ТЗ является основным документом на основании которого ведется разработка ПО. ТЗ имеет юридическую силу на основании его решаются все спорные вопросы которые могут возникнуть или возникают между заказчиком и исполнителем.
ТЗ состовляется на основе ЕСПД(единая система программной документации). Правила оформления документации в ANSI. ТЗ должно содержать следующие разделы:
Введение. Указывается наименование, краткая характеристика области применения программного продукта и обьекта который его использует. Документ на основании которого ведется разработка, организация на основе которой ведется данный документ, наименование.
Назначение разработки. Указывается функциональная и эксплуатоционное назначение программного продукта.
Требования к программному продукту:
Требования к функциональным характеристикам. В под разделе указывается требования к составу выполняемых функций, организация входных и выходных данных, временным характеристикам и тп.
Требования к надежности. В подразделе должны быть указаны требования к надежности, требования входных и выходных данных, обработка вычислений, время восстановления после отказа и тп.
Условия эксплуатации.
Требования к составу и праметрам технических средств.
Требования к информационной и программной совместимости. В данном разделе указываются программные продукты с которыми должна быть совместима программа. Это ОС, прикладное ПО различные системы хранения информации
Требования к маркировке и упаковке.
Требования к транспортировке и хранению.
Требования к программной документации. Требования к программной документаци должен быть указан предварительный состав программной документации и пр необходимости специальнве требования к ней.
Технико-экономические показатели.
Стадия и этапы разработки(календарный план). Устанавливаются необходимые стадии разработки, этапы и содержания работ определяют исполнительные за тот или иной этап.
Порядок контроля и приемки. Указываются каким образом и на основании каких документов осуществляются приемка ПО заказчика.
Унифицированный процесс разработки ПО. Является итеративной моделью предназначеной для реализации программных проектов, имеющих любой масштаб и любой уровень критичности.
Принципы унифицированного процесса:
Начинайте вести наступление на главные риски раньше, и ведите его непрерывно, иначе риски пойдут в наступление на вас.
Обеспечте выполнение требований заказчика. Документируйте требования таким образом, что бы они были понятны заказчикам, и при этом, в ходе проектирования, реализации и тестирования, строго придерживайтесь этих требований, что бы гаранировать их выполнение.
Сконцентрируйтесь на выполняемой программе. Работающая программа лучше документации. Исполняемый код, который компилируется и успешно проходит тесты, лучшмй показатель прогресс разработки ПО.
Приспосабливайтесь к изменениям с самого начала. Современные приложения слишком сложны, что бы можно было получить корректные требования с самого начала, поэтому необходимо быть готовым к тому, что требования будут менятся.
Закладывайте основу исполняемой архитектуры как можно раньше.
Стройте систему из компонентов.
Работайте вместе как одна команда.
Сделайте качество образом жизни, а не запоздалой идеей.
4Р унифицированного процесса.
Персонал. Все заинтересованные лица, учавствующие в процессе.
Процесс. Шаблон для реализации.
Продукт. Результат проекта.
Проект. Набор технических. Управленческих артефактов, необходимых для создания продуктов.
Утилита. С их помощью можно процесс проектирование программной системы; процесс кодирования - путем создания шаблонов кодирования; процесс тестирования - автоматизируя передачу входных данных в систему, симулируя работу внешних систем и аппаратных устройств и тп; процесс создания документации.
Цели начальной фазы:
Понять, что создавать. Определить границы системы.
Выявить ключевые функции системы. Выявить те функции, без реализации которых создание системы не имеет смысла. Данные функции являются наиболее критически в системе.
Выявить хотябы одно возможное решение.
Определить стоимость и риски.
Решить какому процессу следовать и какие средства использовать.
При определении шаблонов процесса вчитывается критичность и маспрошамкал программного проекта, и в зависимости от этого используется тот или иной шаблон. Так же выбирается среда разработки и технологии которые будут использоваться при реализации программного продукта.
Начальная фаза итераций.
Начальная фаза как правило выполняется за одну итерацию, однако, по ряду причин, может потребляемому дополнительные итерации.
Причины:
Проект велик и трудно определить его границы.
Есть множество заинтересованных сторон, взаимоотношение между которыми сложны.
Трудно получить экономическое обосновкние с первого раза.
Существуют большие технические риски которые необходимо уменьшить.
Фаза проектирования.
Цели:
Более глубокое понимание. На начальной фазе выявляемые требования имеют лишь краткое описание либо вообще не имеют такового, поэтому необходимо подробно описать требования и на основе данного описания построить план работы по их реализации.
Спроектировать, реализовать и проверить базавую архитектуру.
Снизить существенные риски и дать более точную оценку срокам и стоимости разработки.
Уточнить прицендент разработки и установить среду разработки.
Итерации фазы проектирования. Фаза проектирования может быть выполнена за одну операцию в том случае, когда имелся опыт работы на подобными проектами и существует возможность использовать ранее полученные решения. В противном случае, тоесть когда задача является новой, может потребоваться дополнительная итерация.
Цели фазы построения:
Снизить стоимость разработки за счет расспараллеливания работ.
Итеративным методом разработать программный продукт.
Фаза пострления как правило выполняется за 2-4 итерации. Каждая итерация включает в себя планирование деятельности на итерацию, до проектирования системы, реализацию и тестирование программного кода. впервой итерации реализуются наиболее критичные сценарии из оставшихся.
Фаза внедрения. Провести бета тестирование системы для выявления. Научить пользователей и обслуживающиц персоонал работать самостоятельно. Для достижения данной цели создается руководство пользователя, проводится обучение персоонала на семинарах.
3. Подготовить площадку для развертывания и конвертировать рабочие базы данных.
Для запуска системы может потребоваться закупка нового оборудования и перевод существующих баз данных в новый формат.
4. Подготовить маркетинговые материалы, выпуск в дистрибуцию и продажу.
5. достич соглашение между всеми заинтересованными сторонами в том, что система готова для выпуска и соответствует критериям определенным в концепции.
6. Повысить производительность при выполнении будующих проектов на основе преобретенного опыта.
Для фазы внедрения может понадобится от 1-2 итераций. Стратегия тестирования.
Источники тестовых данных.
В идеальном случае тестовые данные должны быть подготовлены проектной группой. Эти данные должны помочь понять созданный программный комплекс и служить гарантией того, что программа оправдывает ожидания пользователей. Однако на практике разработка тестовых данных поручаеться программистам. Следствием этого являеться тот факт, что ошибки остаються не обноруженными в плоть до запуска программы в эксплуатацию.
Определение обьема тестирования.
Обьем испытаний может быть ограничен проверкой лишь одной логики, а может заключаться в тестировании каждой ветви ли логического пути в плоть до отдельных логических модулей со всеми комбинациями входных данных. Обычно каждая ветвь программы должна отработать хотя бы один раз. При более тчательном тестировании, каждая ветвь проаеряется на всех входных комбинациях данных, велючая ошибочные. длчпроаедения тестирования необходим формальный подход.
Оценка качества ПО с точки зрения квалиметрии.
Проблемами оценки качечтва занимаеться наука квалиметрия. определяющая основные термины области качества продукции, утанавливающие группы поаазателей качества, определяющая методы получения количественных значений показаний качества и методы определения уровня качества различных образцов промышленой продукции.
Под качеством по будем понимать .... обуславливающих его пригодность удовлетворять его потребности пользоваткдей и специалистов учавствующих в создании и сопровожжении ПО. Из преведенной формулировки следует, что не все свойства ПО входят в его качество, а только та их совокупность которая определяет потребность в этом ПО.
ПЛАНИРОВАНИЕ УРОВНЯ КАЧЕСТВА.
Контроль значения показателей качества в процессе разработки
страница 1
скачать
Другие похожие работы: