рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Планирование рисков. Мониторинг рисков.

Планирование рисков. Мониторинг рисков. - раздел Информатика, Кризис программного обеспечения ПО. Проблемы и цели программной инженерии Последний Этап – Планирование Заключается В Определении Стратегии Управления ...

Последний этап – планирование заключается в определении стратегии управления каждым значимым риском отобранным после их анализа. Не существует единого подхода для разработки. Стратегии управления рисками. Существует 3 категории стратегий управления рисками стратегии предотвращения рисками. Согласно этим стратегиям следует проводить мероприятия снижающие вероятность появления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов.

Минимизационные стратегии от болезней членов команды разработчиков. Планирование аварийных ситуаций. Необходимо иметь план мероприятий, который будет вводиться в действия в случае появления рисковой ситуации. Например – стратегия поведения при возникновении финансовых проблем у организации разработчиков. Мониторинг рисков заключается в регулярном пересчёте вероятности рисков и ущерба который они могут нанести. Для этого необходимо постоянно отслеживать факторы которые влияют на вероятность появления рисков и их возможный ущерб. Эти факторы зависят от типов рисков.

 
Признаки которые помогают определить тип рисков.
 

Тип риска   Признаки
Технологические риски Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документированные технологические проблемы

 
Риски, связанные с персоналом

Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выполненной работы
Организационные риски Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации
Инструментальные риски Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требованиями Необходимость пересмотра многих системных требований, недовольство заказчика ПО  
Риски оценивания Изменения графика работ, многочисленные отчеты о нарушении графика работ

1. Язык моделирования ПО. Концепции объекта и класса.

1.1. UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

1.2. Диаграмма классов (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

1.2.1. концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

1.2.2. точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

1.2.3. точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

1.3. Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

2. Объектно-ориентированный подход в разработке программ [10–12] появился позже других. Его появление стало следствием все возрастающей сложности программного обеспечения, необходимости его регулярного обновления из-за постоянно изменяющихся требований к программам и условиям их функционирования. Именно объектно-ориентированный подход позволяет решать задачи наивысшей сложности, повышает надежность программ, облегчает их модернизацию.

Логическая единица объектно-ориентированной программы – объект. Объект в реальной жизни – это сущность, обладающая некоторым набором свойств и моделью поведения. Объект в программе представляет собой абстракцию реального объекта, т. е. в программе объект наделяется теми чертами и характеристиками реального времени, которые существенны для решаемой задачи. Второстепенные же характеристики в программную абстракцию не включаются, при этом характеристики одного и того же реального объекта, существенные для одной задачи, оказываются второстепенными в другой задаче. Рассмотрим хорошо знакомый нам объект – принтер. Если разрабатывать программу для обслуживания магазина, продающего принтеры, существенными будут модель принтера, цена, габариты, скорость печати, цвет корпуса и т. д. Если рассматривать принтер с точки зрения администратора вычислительной сети, то существенными характеристиками будут логическое имя устройства в сети, его IP-адрес, драйверы, обеспечивающие работу принтера.

Объект в программе имеет имя, ограниченный набор свойств, набор допустимых состояний (т. е. набор конкретных значений свойств), набор методов (операций), определяющих модель поведения объекта (действия объекта).

В программе свойства объекта представлены с помощью переменных, а действия объекта – с помощью подпрограмм (в C++ – функций). Подпрограммы, содержащие описания действий объекта, называются методами. Набор конкретных значений переменных, характеризующих объект, определяет состояние объекта. Объект имеет ограниченный набор допустимых состояний. Например, в нашей модели принтера возможны два состояния: «готов к печати» и «печатает». Остальные свойства задаются для конкретного принтера изначально и не изменяются в процессе работы программы.

Таким образом, объект в объектно-ориентированном программировании (ООП) – это совокупность переменных состояния и связанных с ними методов (операций). Эти методы, с одной стороны, определяют, как объект взаимодействует с внешним миром. С другой стороны, методы осуществляют переход объекта из одного состояния в другое, причем метод проверяет, возможен ли такой переход в данной ситуации. Например, принтеру дается команда отпечатать документ. Если принтер находился в этот момент в состоянии «готов к печати», изменит свое состояние на состояние «печатает». Если принтер в момент получения команды печатал другой документ, то он остается в прежнем состоянии «печатает», а наш документ ставится в очередь на печать. Когда принтер закончит печатать один документ, он приступит к печати нашего документа. Отпечатав наш документ, принтер проверит, есть ли еще документы в очереди на печать, и, если очередь пуста, перейдет в режим «готов к печати». Таким образом, в ответ на наше действие принтер сам определил свои дальнейшие действия, и его выбор зависел от предыдущего состояния принтера. Объектно-ориентированный подход позволяет объектам самим решать, как выполнить ту или иную задачу.

В основе разработки программы с использованием методов ООП применяется объектная декомпозиция задачи. Объектная декомпозиция задачи включает в себя разбиение задачи на отдельные объекты, выявление существенных свойств объектов и способов их взаимодействия. Программа представляет при этом совокупность объектов, взаимодействующих между собой.

В процессе декомпозиции задачи могут быть выявлены объекты с одинаковыми наборами свойств и поведением. Например, для программы, моделирующей футбольный матч, необходимы две команды объектов-«футболистов». Каждого игрока матча можно охарактеризовать следующими свойствами: название команды, форма одежды, номер, координаты на поле. Поведение игроков на поле можно описать следующими действиями: стоит, бежит, отдает мяч, получает мяч. Объекты с одинаковым набором свойств и методов образуют класс. Класс – основа объектно-ориентированной методологии – служит для создания в программе любого количества объектов с заданным набором свойств и заданной моделью поведения. Если проводить параллель с алгоритмической методологией, то класс выступает в роли типа данных, однако это специфический тип, так как кроме данных в класс включаются действия (функции-члены класса, манипулирующие с данными).

Теперь рассмотрим основные термины ООП.

Класс (class) – это тип данных, включающий в себя группу данных различных типов (свойства) и методы работы с этими данными.

Объект (object) – это экземпляр класса, обладающий набором свойств с заданными значениями.

Свойство (property) – характеристика объекта, представленная в виде переменной, являющейся членом класса.

Метод (method) – это подпрограмма, входящая в состав класса и управляющая данными объекта.

Событие (event) – какое-либо происшествие в программе, системе, например, была нажата кнопка мыши.

Сообщение (message) – адресованная конкретному объекту информация о происшедшем событии; объект, получивший сообщение, должен на него ответить своими действиями, вызвав метод, соответствующий этому событию. Например, если получено сообщение о том, что была нажата левая кнопка мыши на пункте меню Exit, произойдет завершение программы, если был выбран пункт меню Save, будет выполнено сохранение информации.

– Конец работы –

Эта тема принадлежит разделу:

Кризис программного обеспечения ПО. Проблемы и цели программной инженерии

Недостатки... Негибкое разбиение процесса создания ПО на отдельные фиксированные этапы... В этой модели определяющие систему в целом решения принимаются на ранних этапах и затем их трудно отменить или...

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Планирование рисков. Мониторинг рисков.

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Кризис программного обеспечения (ПО). Проблемы и цели программной инженерии.
Цели инженерии ПО:Эффективное создание ПС(программных систем). С одной стороны – ПО абстрактно и нематериально, оно не имеет физической природы, не подчин

Основные проблемы, стоящие перед специалистами по ПО.
Проблема наследования ранее созданного ПО,. Проблема наследования означает поддержку и модернизацию существующих систем, причём при минимальных финансовых и временных затрат. Проблема возраста

Профессиональные и этические требования к специалистам по ПО
1) Конфиденциальность: специалист должен соблюдать конфиденциальность, не разглашать сведений о работодателе и клиентах, не зависимо от того, подписывал он какое-либо соглашение или нет. 2) Ком

Окружение системы. Необходимость ее учета при построении систем. Факторы, влияющие на разработку системы.
Любая система зависит от сигналов данных или другой информации поступающей на ее входы .Иными словами система функционирует в определенном окружении, которая влияет на ее интеграционные свойства. И

Моделирование систем. Представление архитектуры системы. Функциональные компоненты систем.
Моделирование системы: В процессе формализации требований к системе и на этапе ее проектирования система рассматривается, как совокупность компонентов и взаимосвязей между

Функциональные компоненты системы.
Их можно классифицировать по ряду категорий: 1) Сенсорный компонент. Собирает информацию о системном окружении. 2) Исполнительный компонент. Производит некоторые действия в окруже

Определение системных требований к системе. Типы требований к системам.
Системные требования — это более детализированное описание пользовательских требований. Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны предста

Проектирование систем
Определяются подсистемы, которые индивидуально или совместно реализуют системные требования, группа требований обычно проецируется на несколько подсистем поэтому можно объединить несколько требован

Разработка подсистем. Сборка системы.
Разработка подсистем На этом этапе реализуются те подсистемы, которые были определены на предыдущем этапе. Тут есть три варианта: 1. Разработка системы с нуля

Аттестация программных систем. Процесс тестирования систем. Альфа и бета тестирование.
Аттестация ПО предназначена показать соответствие системы, ее спецификации, а также ожиданиям и требованиям заказчика и пользователя. За исключением небольших программ, программные системы невозмож

Эволюция систем.
Большие системы имею очень долгий срок жизни в течение которой они совершенствуются путём исправления ошибок в исходных системных требованиях, а так же для учёта новых требований предъявляемых к ни

Каскадная модель
Основные этапы этой модели отражают все базовые виды деятельности необходимые д

Эволюционная модель разработки ПО.
Разрабатывается версия программного продукта которая передаётся пользователям. Затем она дорабатывается с учётом мнения пользователя. В результате имеем промежуточную версию, которая снова проходит

Разработка ПО на основе ранее созданных компонентов.
В большинстве программных проектах применяется повторное использование, некоторых программных модулей, эти компоненты модифицируются в соответствии с требованиями, и затем включаются в состав новой

Модель пошаговой разработки ПО.
Процессы специфицирования требований проектирования, проектирования и написания кода разбивается на последовательность небольших шаблонов, которые ведут к созданию ПО. Эта модель была пред

Спиральная модель разработки ПО.
Каждый виток спирали соответствует одной стадии (итерации), процесса создания ПО. Самый внутренний виток, соответствует стадии принятия решения о создании ПО. На следующем витке определяются систем

Управление проектами. Процессы управления.
Руководители программных проектов выполняют такую же работу что и руководители технических проектов, вместе с тем процесс разработки ПО Имеет ряд существенных отличий, что порождает определённые сл

Процессы управления.
1. Написание предложений по созданию ПО. Предложения должны содержать описании целей проекта и способов их достижения. Оценку финансовых и временных затрат на выполнение проекта, а так же обоснован

Планирование проекта.
Эффективное управление программным проектом, напрямую зависит от правильного планирования работ, необходимого для его выполнения, план помогает предвидеть проблемы, которые могут возникнуть на како

Контрольные отметки этапов работ.
При планировании процесса определяются контрольные отметки отмечающие окончания определённого этапа работ. Для каждой контрольной отметки создаётся отчёткоторый предоставляется руководству проекта,

Сетевые и временные диаграммы.
Временные и сетевые диаграммы полезны для представления графика работ. Временная диаграмма показывает время начала и окончания каждого этапа и его длительность, позволяют в наглядной форме показыва

Этапы некоторого проекта.
Этап Длительности (дни) Зависимость Т1   Т2

Типа рисков.
1. Риски для проектов – влияют на график работ или ресурсов необходимые для реализации проекта, 2. Риски для разрабатываемого продукта, влияют на качество или производительность разрабатыв

Определение рисков.
Процесс определения рисков состоит из 3 стадий. 1. Определение рисков - Определяются возможные риски для проекта, разрабатываемого продукта и бизнес риски. 2. Анализ рисков - оцен

Анализ рисков.
Анализ рисков, при анализе для каждого определённого риска подсчитывается вероятность его появления и ущерб который он может нанести, не существует простых методов выполнения анализа рисков, в знач

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги