Управление качеством в процессе разработки программного обеспечения предприятия
Описание предприятия, работающего в сфере информационных технологий. Изучение продукции, поставщиков, проблем и перспектив развития предприятия. Анализ процедуры проектного управления. Характеристика особенностей разработки схемы программного обеспечения.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 19.11.2017 |
| Размер файла | 196,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Введение
- Глава 1. Описание предприятия
- 1.1 Продукция
- 1.2 Потребители
- 1.3 Поставщики
- 1.4 Проблемы и перспективы развития
- 1.5 Краткое описание структуры дипломного проекта
- Глава 2. Проект процедуры проектного управления
- 2.1 Описание процедуры проектного управления
- 2.1.1 Состав процедуры
- 2.2 Анализ требований
- 2.2.1 Состав процедуры
- 2.2.2 Определение ожиданий заказчика
- 2.2.3 Определение проектных и корпоративных ограничений
- 2.2.4 Определение внешних ограничений
- 2.2.5 Определение сценариев функционирования и применения
- 2.2.6 Определение измерителей эффективности и годности
- 2.2.7 Определение границ системы
- 2.2.8 Определение интерфейсов
- 2.2.9 Определение внешних условий функционирования
- 2.2.10 Определение концепции процессов жизненного цикла
- 2.2.11 Определение функциональных требований
- 2.2.12 Определение требований к рабочим характеристикам
- 2.2.13 Определение режимов работы
- 2.2.14 Определение измерителей технической производительности
- 2.2.15 Определение физических характеристик
- 2.2.16 Определение человеческого фактора
- 2.2.17 Установка основной версии требований
- 2.3 Подтверждение требований
- 2.3.1 Состав процедуры
- 2.3.2 Сравнение с ожиданиями заказчика
- 2.3.3 Сравнение с проектными и корпоративными ограничениями
- 2.3.4 Сравнение с внешними ограничениями
- 2.3.5 Определение расхождений и противоречий
- 2.3.6 Подтверждение основной версии требований
- 2.4 Функциональный анализ
- 2.4.1 Состав процедуры
- 2.4.2 Анализ функционального контекста
- 2.4.3 Функциональная декомпозиция
- 2.4.4 Установка функциональной архитектуры
- 2.5 Проверка функциональной архитектуры
- 2.5.1 Состав процедуры
- 2.5.2 Определение процедур проверки
- 2.5.3 Проведение проверочной оценки
- 2.5.4 Выявление расхождений и конфликтов
- 2.5.5 Установка проверенной функциональной архитектуры
- 2.6 Дизайн синтез
- 2.6.1 Состав процедуры
- 2.6.2 Группировка и выделение функций
- 2.6.3 Выявление альтернативных конструкционных решений
- 2.6.4 Оценка надежности, опасности вредного воздействия окружающей среды
- 2.6.5 Оценка факторов качества жизненного цикла
- 2.6.6 Оценка требований к технологии
- 2.6.7 Выделение физических и рабочих характеристик
- 2.6.8 Определение физических интерфейсов
- 2.6.9 Оценка возможности использования стандартных элементов
- 2.6.10 Оценка наличия стандартных элементов
- 2.6.11 Оценка альтернативы «произвести или купить»
- 2.6.12 Разработка моделей, изготовление прототипов
- 2.6.13 Оценка видов отказов, их последствий и критичности
- 2.6.14 Оценка необходимости тестирования
- 2.6.15 Оценка возможности конструкции к доработке
- 2.6.16 Завершение конструирования
- 2.6.17 Инициирование эволюционной разработки
- 2.6.18 Изготовление чертежей и схем
- 2.6.19 Установка физической архитектуры
- 2.7 Проверка физической архитектуры
- 2.7.1 Состав процедуры
- 2.7.2 Выбор принципа (метода) проверки
- 2.7.3 Проведение проверочной оценки
- 2.7.4 Выявление расхождений и конфликтов
- 2.7.5 Установка проверенной физической архитектуры
- 2.7.6 Проверка физической архитектуры процесса жизненного цикла
- 2.7.7 Составление проверенной системной архитектуры
- 2.7.8 Установка основных версий спецификации и конфигурации
- 2.7.9 Разработка дерева системы
- 2.8 Системный анализ
- 2.8.1 Состав процедуры
- 2.8.2 Оценка конфликтов требований
- 2.8.3 Оценка альтернативных вариантов функциональности
- 2.8.4 Оценка альтернативных решений
- 2.8.5 Выявление факторов риска
- 2.8.6 Определение области исследования
- 2.8.7 Проведение исследования
- 2.8.8 Выбор параметров управления риском
- 2.8.9 Выбор альтернативных рекомендаций
- 2.8.10 Документирование компромиссного решения и воздействия
- 2.8.11 Оценка эффективности решения
- 2.9 Контроль
- 2.9.1 Состав процедуры
- 2.9.2 Техническое управление
- 2.9.3 Прослеживание данных системного анализа и проверки/тестирования
- Глава 3. Творческая форма функционально-стоимостного анализа в проектах разработки программного обеспечения
- 3.1 Функционально-стоимостной анализ
- 3.2 Этапы творческой формы ФСА
- 3.3 Функции объекта и их классификация
- 3.3.1 Классификация функций
- 3.4 Анализ функционально-структурных (совмещенных) моделей
- 3.4.1 Расчет затрат на реализацию функций в ФСА
- Глава 4. Организация обстановки для умственного труда
- 4.1 Введение
- 4.2 Анализ ПЭБ при эксплуатации персональных компьютеров
- 4.2.1 Перечень факторов обитаемости
- 4.2.2 Микроклимат
- 4.2.3 Шум
- 4.2.4 Нерациональное освещение
- 4.2.5 Электроопасность
- 4.2.6 Комплексная оценка жизнедеятельности и возможности возникновения опасных ситуаций
- 4.3 Расчет искусственного освещения
- 4.4 Выводы
- Заключение
- Список литературы
Введение
Управление качеством в процессах разработки ПО
Стандарт ISO 9000-2000
По ISO, качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям [1]. Современные способы обеспечения качества базируются на подходах TQM (Total Quality Management). Это управление ресурсами и применение количественных методов анализа для улучшения материалов и услуг, поставляемых в организацию, всех процессов внутри организации, а также степени удовлетворенности настоящих и будущих потребностей клиентов.
Активное внедрение подходов качества в США и Европе началось в начале 1960-х годов. Если говорить о программировании, то идеи качества пришли сюда из промышленности в ответ на кризис конца 1960-х годов.
В основу построения организационной системы по ISO 9000-2000 закладываются следующие принципы:
· Концентрация на потребностях заказчика.
· Активная лидирующая роль руководства.
· Вовлечение исполнителей в процессы совершенствования.
· Реализация процессного подхода.
· Системный подход к управлению.
· Обеспечение непрерывных улучшений.
· Принятие решений на основе фактов.
· Взаимовыгодные отношения с поставщиками.
При этом методически, в полном соответствии с дисциплиной построения сложных систем, стандарт ISO 9000-2000 предусматривает, с одной стороны, построение организационной системы «сверху вниз»: от целей предприятия и его политики - к организационной структуре и формированию бизнес процессов, и с другой - итеративное развитие организационной системы через механизмы измерения и улучшения.
Цена качества
В программировании в цене качества выделяют согласованную (conformance) и несогласованную (non-conformance) цену. Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий. Несогласованная цена - это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т. д.
Статистические исследования на реальных проектах показывают, что несогласованная цена качества уменьшается существенно быстрее, чем увеличивается согласованная цена. Фактически это означает, что затраты на качество, безусловно, выгодны и должны окупаться не только в перспективе через расширение рынка, но и непосредственно в каждом текущем проекте.
Трудность в том, чтобы спланировать и отслеживать затраты на качество в прямой зависимости от получаемых результатов. То есть речь идет об управлении качеством. Одна из основополагающих идей TQM состоит в том, что мы можем управлять качеством разрабатываемого продукта в основном через процесс его изготовления.
Качество продукта возрастает на каждой стадии процесса: во-первых, как прямое следствие зрелости и технологичности самого процесса, и во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей стадии, более высокого качества. То есть при сложном производстве качество накапливается в продукте кумулятивным образом, причем вклад в качество, сделанный на ранних стадиях, больше влияет на конечный продукт, чем вклад, сделанный на заключительных этапах. Если говорить о цифрах, то прибыль от затрат на качество в бюджетах проектов может составлять от 50 до 200%, при условии их адресности и своевременности.
Что касается более долгосрочных инвестиций, например, в индустриальную систему качества, соответствующую стандарту качества CMM (capability maturity model), то, по данным Software Engineering Institute, уровень возврата инвестиций при внедрении систем качества в среднем достигает значения 5.
Формирование процесса разработки программного обеспечения
Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP). Однако если под качеством понимать степень удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование всех требований и возможность измерения степени выполнения требований в готовящейся версии программы. Возможная «утечка» качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.
В полной мере управлять качеством можно, если оно измеряется на всех этапах жизненного цикла. Качество к промежуточному продукту может быть установлено на основе отраслевых стандартов, в данном случае стандартов программирования (например, ISO или IEEE).
Вероятно, одной из самых больших трудностей, связанных с формированием процессов разработки ПО, является обеспечение целостности и согласованности всех действий и требуемых результатов. Особенно это важно для проектов, которые выполняются многочисленной командой разработчиков. Например, обычной ситуацией является изменение требований или проектных решений в процессе разработки; в этом случае должны быть каскадно изменены и приведены в соответствие все связанные, разработанные к этому времени промежуточные продукты и документы. Беда в том, что это требует высоких трудозатрат, нередко выполняется не полностью и приводит к потере качества продукта. Поэтому важно, чтобы процесс был высоко автоматизирован и поддерживался инструментальными средствам не только в части основных программных процессов, но и в отношении вспомогательных процессов, таких как конфигурационное управление, документирование и т. п. При этом важно использовать интегрируемые между собой инструментальные средства для обеспечения автоматической прослеживаемости связанных промежуточных результатов проекта. В качестве примера таких инструментальных средств можно назвать семейство продуктов Rational Software.
Сертификация системы менеджмента качества
В ISO 9000-2000 заложена идея разделения контроля по уровням управления. Мониторинг, внутренние аудиты должны проводиться в рамках проектов и на уровне руководства фирмы. По сути, существует еще и управление со стороны клиентов. Если говорить о профессиональном контроле систем менеджмента качества, то его выполняют внешние аудиторы, которые могут рассматриваться как представители клиентов и партнеров компании. Таким образом, без внешнего сертификационного аудита внедрение систем качества на предприятиях не может быть полным.
За пределами ISO 9000-2000
На вопрос, гарантирует ли внедрение системы качества и успешная сертификация выпуск качественного продукта, следует ответить обескураживающее «нет». Подчеркивая, что ISO 9000 - «превосходная идея», Gartner Group рекомендует рассматривать сертификацию на ISO 9000-2000 только как исходную точку на пути к качеству. Стандарт ISO 9000 является достаточно простым и общим. Постоянное наполнение системы качества профессиональным содержанием на основе уже специальных, отраслевых стандартов и методологий может обеспечить уровень качества, соответствующий растущим требованиям рынка. Поэтому главное, что должна выполнять компания в области качества, - это не останавливаться на достигнутом.
Глава 1. Описание предприятия
ООО «РУСОФТ» - компания, работающая в сфере информационных технологий, была основана и внесена в реестр Торгово-промышленной палаты России в 2000 году. Специализацией компании в настоящее время является внедрение информационных технологий, в том числе с использованием средств Интернет, в бизнес процессы заказчика [2].
В начале своего существования компания занималась только созданием прикладного программного обеспечения. В частности, первым проектом компании был проект создания комплекта программного обеспечения (системы) для управления дисковыми RAID-массивами GUI MAN для испанской компании Fibrenetix Storage Inc. Проект был достаточно продолжительным, его реализации заняла полтора года работы. Проект можно считать успешным, так как он завершился точно в срок, а заказчик был полностью удовлетворен функциональностью системы. В последствии система дважды успешно выставлялась на выставке CiBit в Ганновере в 2000 и 2001 годах.
Со временем компания Русофт стала принимать участие в проектах разработки программного обеспечения, ориентированного на Интернет и столкнулась с необходимостью интеграции интернет-технологий с бизнес процессами заказчика. Было принято решение о расширении поля деятельности компании и, в результате, компания обзавелась отделом веб-дизайна и интернет-разработок. Постепенно разработки интернет-приложений стали основным направлением деятельности компании.
В июне 2001 года компания Русофт заключило партнерское соглашение с американской компанией Internet Pictures Corporation, получив эксклюзивное право на распространение технологии iPIX в России. В результате этого в сфере деятельности компании появилось новое направление - распространение продукции и технологии создания панорамных изображений с возможностью обзоры 360 x 360 градусов. Данная технология до сих пор находит широкое применение на сайтах в Интернет и других местах публикации информации в электронном виде, как то CD-презентации. Другими словам везде, где есть задача предоставить зрителю пространственное представление об интерьере, ландшафте, событии или предмете.
Кроме всего выше перечисленного компания Русофт представляет интересы ирландской компании Mentec в России. Компания Mentec известна, кроме всего прочего, своими разработками в области переноса программ со старых DEC-совместимых компьютеров (PDP11, LSI-11) на современные PC-совместимые платформы.
Таким образом, компания Русофт работает в следующих направлениях:
· Разработка программного обеспечение для сети Интернет и интеграция разработанных программных комплексов в бизнес процессы заказчика
· Интернет-маркетинг
· Распространение технологии iPIX
· Миграция программного кода с DEC-совместимых компьютеров на PC
1.1 Продукция
Как говорилось выше, компания Русофт специализируется на разработке заказного программного обеспечения. Таким образом, продукцией компании является программное обеспечение, либо разработанное «с нуля», либо собранное из готовых модулей с доработкой под нужды заказчика.
В данной работе основное внимание будет уделяться разработке программного обеспечения для сети Интернет:
· Корпоративные информационные системы (КИС) с веб-интерфейсом
· Интернет-сайты (сайты)
1.2 Потребители
В результате своей деятельности в течение свыше четырех лет и, благодаря портфолио завершенных проектов, компания Русофт получила широкую известность. Среди прочих, потребителями продукции и услуг компании являются средние и крупные промышленные компании, государственные структуры, СМИ, туристические организации, страховые компании, автосалоны и др., осознавшие необходимость в предоставлении информации о себе, своей продукции и услугах в Интернет.
Конечными пользователями продукции являются:
1. В случае разработки КИС для внутреннего использования - сотрудники компании-заказчика
2. В случае разработки сайта - посетители сайта (пользователи сети Интернет) с одной стороны и сотрудники компании-заказчика - с другой
1.3 Поставщики
Поставщиками компании Русофт являются предприятия, предоставляющие телематические услуги: доступ к информационным ресурсам городской сети, доступ в Интернет. Главным поставщиком телематических услуг на данный момент является ООО «СИНС-ТЕЛЕКОМ».
1.4 Проблемы и перспективы развития
Проектная деятельность компании строиться на словах и устных договоренностях, не закреплена в документированных процедурах, а, следовательно, не воспроизводима и зависит от носителей знаний. Для устранения этих недостатков необходимо создать нормативную основу для документирования деятельности предприятия. Первым шагом в этом направлении явилось принятие решение о проведении исследования по разработке комплекта нормативной документации, основной частью которого является процедура проектной деятельности в части управления требованиями. Разработка 1-го проекта этой процедуры и является основной задачей дипломного проекта.
1.5 Краткое описание структуры дипломного проекта
Пояснительная записка к дипломному проекту состоит из четырех глав:
1. Описание предприятия.
2. Проект процедуры проектного управления.
3. Творческая форма функционально-стоимостного анализа в проектах разработки программного обеспечения.
4. Организация обстановки для умственного труда.
В первой главе кратко охарактеризована деятельность компании Русофт, описана производимая ею продукция, производители и поставщики.
Во второй граве представлен первый проект разрабатываемой процедуры, приведена информация об общей структуре процедуры, дано детальное описание всех операций.
В третьей главе представлен теоретический материал о творческой форме функционально-стоимостного анализа, дана классификация функций объекта, описана методика анализа структурно-функциональной диаграммы и метод расчета затрат на реализацию функций объекта.
В четвертой главе изложены результаты анализа ПЭБ при работе с компьютером, охарактеризованы основные источники опасности, проведен расчет искусственного освещения.
Глава 2. Проект процедуры проектного управления
На предстоящем этапе формирования документа будет принят следующий глоссарий терминов.
Дерево изделия - это иерархическое деление изделия на составные части. Каждый нижестоящий уровень структуры представляет собой детализацию вышестоящего уровня.
Структурный план работ - это иерархическое деление всех работ по проекту с целью обеспечения его контроля и управления.
При разработке проекта процедуры будем опираться на [3] и [4].
2.1 Описание процедуры проектного управления
Областью применения процедуры проектного управление является проектная деятельность вплоть до реализации плана проекта.
Владелец: технический руководитель проекта.
Входами процедуры являются:
· Потребности, задачи, требования заказчика
· Требования спецификаций и стандартов
Выходами процедуры являются:
· Архитектура системы (дерево продукта)
· Спецификации
- 2.1.1 Состав процедуры
Процедура проектного управления состоит из следующих процедур:
· Анализ требований
· Подтверждение требований
· Функциональный анализ
· Проверка функциональной архитектуры
· Дизайн синтез
· Проверка физической архитектуры
· Системный анализ
· Контроль
Структурная схема процедуры проектного управления представлена на рис. 2.1.
Рис. 2.1 Структурная схема процедуры проектного управления
2.2 Анализ требований
Целью процедуры является составление основной версии требований.
Задачами процедуры являются:
· определение того, что система должна делать и насколько хорошо;
· определение внешних условий функционирования системы;
· определение ограничений, влияющих на исполнение системы.
·
2.2.1 Состав процедуры
Процедура состоит из следующих операций:
· Определение ожиданий заказчика
· Определение проектных и корпоративных ограничений
· Определение внешних ограничений
· Определение функциональных сценариев и сценариев использования
· Определение измерителей эффективности и пригодности
· Определение границ системы
· Определение интерфейсов
· Определение окружения функционирования
· Определение концепции процессов жизненного цикла
· Определение функциональных требований
· Определение требований к рабочим характеристикам
· Определение режимов функционирования
· Определение измерителей технической производительности
· Определение физических характеристик
· Определение человеческого фактора
· Установка основной версии требований
Структурная схема процедуры изображена на рис. 2.2.
2.2.2 Определение ожиданий заказчика
Ожидания заказчика можно выявить из документов с перечнем требований к функционированию, документов с описанием миссии и задач разрабатываемой системы, из прямых диалогов с заказчиком или из требований системы более высокого уровня, в которую разрабатываемая система входит как составная часть.
Рис. 2.2 Структурная схема процедуры «Анализ требований»
Целью этой операции является определение того, чего действительно хочет заказчик от разрабатываемой системы в отражении того, какие функции она должна выполнять и насколько качественно.
Описание требований также может включать в себя описание естественного или смоделированного окружения, в котором должны функционировать продукты системы, а также различные ограничения, например, размер и порядок финансирования проекта, стоимость, ценовая политика и цели, которые она преследует, ограничения по срокам проекта и его расписанию, по используемым технологиям, ограничения к физическим характеристикам, перечень неразрабатываемых и повторно используемых частей.
Ожидания заказчика Интернет-системы:
CR1. Разработать сайт не хуже, чем у конкурентов (дизайн).
CR2. Сайт должен показывать, что компания является лидером в своей области (дизайн).
CR3. Дизайн сайта должен быть красивым, стильным, должен впечатлять посетителя.
CR4. Дизайн не должен быть перегружен графикой, должен быть легким.
CR5. У компании есть свой фирменный стиль и логотип. Дизайн сайта должен соответствовать фирменному стилю и использовать логотип компании в своем оформлении.
CR6. Основными посетителями сайта будут являться люди в возрасте от 17 до 55 лет, для них необходимо предоставить полную информацию об ассортименте продукции компании.
CR7. Структура каталога продукции должна соответствовать предложенной заказчиком.
CR8. Система должна защищать информацию от несанкционированного изменения, должна позволять управлять несколькими пользователями с различными уровнями доступа (доступ к разным модулям системы администрирования, к редактированию разных разделов сайта)
CR9. Система администрирования должна позволять делать следующее:
· Менять структуру разделов на сайте
· Менять содержимое разделов сайта и каталога продукции
· Загружать на сайт файлы документов и рисунков
CR10. Защитить информацию от потери
2.2.3 Определение проектных и корпоративных ограничений
Проектные ограничения могут включать в себя:
· Одобренные спецификации и основные версии документов, разработанные во время предшествующих применений процесса проектного управления
· Стоимость
· Измененный технический план и план менеджмента проекта
· Состав и структура команды проекта
· Механизмы контроля
· Требуемые метрики измерения прогресса процесса
Корпоративные ограничения могут включать в себя:
· Управленческие решения из предшествующих технических оценок
· Основные спецификации компании
· Стандартны и руководящие указания
· Методики, принципы и процедуры
· Технологии производственной сферы
· Распределение физических, финансовых и людских ресурсов по проекту
Проектные ограничения:
Финансовые ресурсы проекта: $2000
Временные ресурсы проекта: 20 рабочих дней
Состав и структура команды проекта:
|
Роль |
Количество |
|
|
Администратор проекта |
1 |
|
|
Менеджер проекта |
1 |
|
|
Дизайнер |
2 |
|
|
HTML верстальщик |
1 |
|
|
Программист-проектировщик |
1 |
Механизмы контроля: приемка каждого этапа структурного плана работ внутренним или внешним заказчиком.
Корпоративные ограничения:
При разработке должен использоваться framework “SMS” версии 3.1;
Сайт и система администрирования должны разрабатываться с использованием следующих технологий и языков: HTML, CSS, JavaScript, PHP, SQL;
PHP и JavaScript код должен соответствовать стандарту кодирования, принятому в организации разработчика;
Сайт и система администрирования должны в одинаковой степени функционировать на серверной площадке с операционными системами Windows, Linux, FreeBSD, под управлением веб-сервера Apache 1.3.xx с модулем PHP 4.3.9 и выше (с установленным модулем Zend Optimizer) и сервера баз данных mySQL 4.0 и выше;
Генерируемый системой код должен одинаково правильно функционировать в следующих Интернет броузерах:
· Microsoft Internet Explorer 4.01 и выше
· Opera 7 и выше
· Mozilla 1.7 и выше
· Firefox 1.0 и выше
При разработке необходимо руководствоваться следующими стандартами:
· Генерируемый системой HTML код должен соответствовать стандарту XHTML 1.0 Transitional;
· CSS код должен соответствовать стандарту CSS 2.0;
SQL код должен соответствовать нотации SQL 92.
2.2.4 Определение внешних ограничений
Внешние ограничения могут включать в себя:
· Общественные и международные правила и законы
· Технологическая база
· Требования, технические условия: стандартов и основных спецификаций отрасли, международных стандартов, руководящих указаний
· Возможности системы безопасности
· Возможности интерфейсных систем
Внешних ограничений нет.
2.2.5 Определение сценариев функционирования и применения
Эксплуатационные сценарии должны охватывают все варианты использования системы и ее продуктов.
Для каждого эксплуатационного сценария описать ожидаемые:
· Взаимодействия с внешними условиями и другими системами
· Взаимосвязи с интерфейсными системами, платформами или продуктами
Варианты использования Интернет-системы:
Сайт:
· Просмотреть интересующую информацию
· Найти продукт по параметрам
· Отправить письмо в службу работы с клиентами
Система администрирования:
· Войти в систему
· Выйти из системы
· Создать пользователя
· Изменить информацию о пользователе
· Удалить пользователя
· Создать группу пользователей
· Изменить название группы
· Назначить права доступа для группы
· Добавить пользователя в группу
· Удалить группу
· Создать раздел
· Изменить информацию раздела (текст, графику, мета-тэги)
· Изменить позицию раздела в дереве
· Удалить раздел
2.2.6 Определение измерителей эффективности и годности
Измерители (свойства) эффективности системы должны отражать реализацию всех ожиданий заказчика и его удовлетворение, а также то, насколько хорошо система выполняет возложенные на нее задачи.
2.2.7 Определение границ системы
Границы системы должны включать в себя:
· Описание того, какие элементы системы находятся под конструкционным контролем, а какие за его пределами;
· Предполагаемое взаимодействие между элементами системы, находящимися под конструкционным контролем, и внешними элементами или другими системами более высокого уровня.
2.2.8 Определение интерфейсов
Функциональные и физические интерфейсы к внешним или высокоуровневым системам, находящимся за границами разрабатываемой системы, могут включать механические, электрические, термальные взаимодействия, а так же взаимодействия потоков данных, процедурные и управляющие воздействия.
Интерфейсы так же могут быть рассмотрены с внутренней и внешней точки зрения.
Внутренние интерфейсы описывают взаимодействие элементов в пределах границы системы. Эти интерфейсы устанавливаются подрядчиком, ответственным за разработку системы.
Внешние интерфейсы - это интерфейсы, описывающие взаимодействие между внутренними элементами системы, находящимися в пределах границы системы, и внешними, находящимися за пределами границы системы. Эти интерфейсы обычно устанавливаются общепринятыми стандартами.
2.2.9 Определение внешних условий функционирования
Внешние условия могут включать погодные, температурные условия, географическое размещение, различные индуцированные условия применения, например вибрации, электромагнитное излучение, химическое воздействие, а так же другие внешние факторы окружающей среды, в которой возможно использование системы.
2.2.10 Определение концепции процессов жизненного цикла
Проанализировать выходы операций с 2.2.2 по 2.2.9 для выявления ключевых моментов процесса жизненного цикла системы, которые необходимо учитывать при разработке, производстве, тестировании, распространении, использовании, поддержке, обучении и уничтожении продуктов системы в процессе разработки.
2.2.11 Определение функциональных требований
Функциональные требования должны отражать ожидания заказчиков, удовлетворять ограничениям. Функциональные требования, определенные в результате анализа требований, в дальнейшем будут декомпозированы во время выполнения процедуры Функциональный анализ.
Проведем QFD анализ для выявления высокоуровневых функциональных требований и их относительного веса из ожиданий заказчика, с учетом веса каждого ожидания заказчика [5]. Результаты представлены в таблице 2.1.
Ф1. Предоставлять информацию по запросу
Ф2. Управлять содержанием и структурой информации
Ф3. Обеспечивать защиту информации от несанкционированного изменения и удаления
Ф4. Обеспечивать защиту информации от потери
Ф5. Оформлять предоставляемую информацию
Таблица 2.1
|
Функциональные требования |
|||||||
|
Эксплуатационные требования |
Ф1 |
Ф2 |
Ф3 |
Ф4 |
Ф5 |
Важность |
|
|
CR1 |
3 |
||||||
|
CR2 |
3 |
||||||
|
CR3 |
3 |
||||||
|
CR4 |
5 |
||||||
|
CR5 |
5 |
||||||
|
CR6 |
5 |
||||||
|
CR7 |
3 |
||||||
|
CR8 |
5 |
||||||
|
CR9 |
4 |
||||||
|
CR10 |
5 |
||||||
|
Абсолютный вес ФТ |
54 |
36 |
45 |
45 |
135 |
||
|
Относительный вес ФТ |
0,17 |
0,12 |
0,14 |
0,14 |
0,43 |
- сильная связь, - средняя связь, - слабая связь.
Вес связи соответственно 9, 3, 1.
2.2.12 Определение требований к рабочим характеристикам
Определить и описать требования к рабочим характеристикам для каждой высокоуровневой функции, выполняемой системой.
2.2.13 Определение режимов работы
Описание режимов работы должно включать в себя так же описание условий (внешних условий, конфигурации, эксплуатационных условий и т.д.), которые определяют данный режим работы.
2.2.14 Определение измерителей технической производительности
Измерители технической производительности - основные индикаторы производительности системы. Они будут отслеживаться во время процесса конструирования. Измерители технической производительности должны быть ограничены пороговой величиной таким образом, что при выходе за границы этой величины проект подвергается стоимостному, временному или производительному риску.
Для Интернет-системы это время, которое пройдет от момента отправки запроса пользователем до момента завершения выполнения запроса. Измеряется в миллисекундах (мс).
2.2.15Определение физических характеристик
К физическим характеристикам относятся цвет, текстура, размер, вес и т.д. Определить, какие физические характеристики - неизменные константы, а какие могут быть изменены в процессе проектирования.
2.2.16 Определение человеческого фактора
Описание человеческого фактора может включать в себя:
· различные эргономические характеристики;
· описание портрета потенциального пользователя;
· окружение пользователя в момент работы с системой.
Портрет пользователя Интернет-системы:
Пользователь ПК, имеющий навыки работы и поиска информации в Интернет, владеющий русским языком, работающий в спокойной обстановке.
2.2.17 Установка основной версии требований
Основная версия требований является результатом выполнения предыдущих операций.
Основная версия требований документируется в трех представлениях: эксплуатационном, функциональном и физическом
Основная версия требований устанавливает и характеризует проблему, подлежащую разрешению последующим применением процедур.
Эксплуатационное представление описывает то, как продукты системы будут обслуживать пользователей. Оно описывает варианты и условия использования системы.
Функциональное представление описывает то, что система должна делать для того, чтобы выполнять запросы пользователей, описанные в эксплуатационном представлении.
Физическое представление описывать взгляд на систему с точки зрения ее физических компонентов и устанавливает требования к технологиям и физическим интерфейсам между элементами системы и между элементами системы и пользователем.
2.3 Подтверждение требований
2.3.1 Состав процедуры
Процедура состоит из следующих операций:
· Сравнение с ожиданиями заказчика
· Сравление с проектными и корпоративными ограничениями
· Сравнение с внешними ограничениями
· Определение расхождений и противоречий
· Подтверждение основной версии требований
Структурная схема процедуры изображена на рис. 2.3.
Рис. 2.3 Структурная схема процедуры «Подтверждение требований»
2.3.2 Сравнение с ожиданиями заказчика
Основная версия требований анализируется и сравнивается с ожиданиями заказчика для того, чтобы удостовериться, что технические требования адекватно отражают потребности заказчика, требования и ограничения к продуктам системы и концепции жизненного цикла поддержки системы.
2.3.3 Сравнение с проектными и корпоративными ограничениями
Основная версия требований анализируется и сравнивается с проектными и корпоративными ограничениями, для того, чтобы удостовериться, что технические требования отражают проектные и корпоративные политики, процедуры, принимаемый уровень риска, планы, ресурсы, технологические ограничения, цели, решения, стандарты или другие документированные ограничения, и соответствуют им.
2.3.4 Сравнение с внешними ограничениями
Основная версия требований анализируется и сравнивается с проектными и корпоративными ограничениями, для того, чтобы удостовериться, что технические требования отражают требования применяемых национальных и международных стандартов, правильно отражают требования внешних интерфейсов к существующим или выделенным системам, платформам или продуктам.
2.3.5 Определение расхождений и противоречий
Выявляются и описываются расхождения и противоречия, которые выявляются во время предыдущих трех действий. Каждое расхождение или противоречие должно быть разрешено в итерационном цикле с процедурой Анализ требований для переопределения основной версии требований.
2.3.6 Подтверждение основной версии требований
Основная версия требований подтверждается, как только все расхождения и противоречия успешно разрешены.
Подтвержденная основная версия требований используется на входе процедуры Функциональный анализ.
2.4 Функциональный анализ
Цели процедуры:
· Более подробно описать проблему, определенную на этапе Анализа требований
· Декомпозировать функции системы на более детальные, которые будут выполняться отдельными частями системы (компонентами, подсистемами и т.п.)
Анализ выполняется путем перевода утвержденной основной версии требований в функциональную архитектуру. Функциональная архитектура описывает функциональные схемы и последовательности подфункций, получаемых при декомпозиции (разбиении) множества системных функций до их подфункций. Функциональный анализ проводится без принятия во внимание конструкционного исполнения.
предприятие обеспечения программный
2.4.1 Состав процедуры
Процедура состоит из следующих операций:
· Анализ функционального контекста
o Анализ функционального поведения
o Определение функциональных интерфейсов
o Выделение требований к рабочим характеристикам
· Функциональная декомпозиция
o Определение подфункций
o Определение состояний и режимов подфункций
o Определение временных параметров функций
o Определение потоков данных и потоков управления
o Определение режимов сбоя функции и реакции на сбой
o Определение функций отслеживания опасности
· Установка функциональной архитектуры
Структурная схема процедуры изображена на рис. 2.4.
2.4.2 Анализ функционального контекста
Данным действием необходимо анализировать каждую системную функцию для выявления выходов системы в зависимости от входов. Анализ проводится для понимания функционального поведения системы в различных условиях и для оценки целостности функциональной архитектуры. Анализ включает в себя моделирование или стимуляцию функциональных моделей, использующих эксплуатационные сценарии, которые подвергают модели воздействию разнообразных стрессовых и не стрессовых ситуаций, которые отражают предполагаемые варианты эксплуатации системы и внешние условия.
Определение функциональных интерфейсов
Во время декомпозиции системных функций на более мелкие, между взаимодействующими функциями создаются интерфейсы. Данным действием необходимо выявить эти интерфейсы и определить их функциональные взаимосвязи, такие как начальное и конечное состояние, или входы и выходы.
Рис. 2.4 Структурная схема процедуры «Функциональный анализ»
Выделение требований к рабочим характеристикам
Данное действие распределяет рабочие характеристики системы по функциям для предоставления их прослеживаемости и облегчения возможных изменений в будущем.
2.4.3 Функциональная декомпозиция
Данное действие декомпозирует функции системы на подфункции с целью определения:
· альтернативных функциональных схемы и последовательностей,
· их функциональных интерфейсов,
· их рабочих характеристик.
Протяженность функциональной декомпозиции зависит от установления четкого понимания того, что системы должна выполнять.
Оценка затрат и анализ рисков проводятся для того, чтобы определить оптимальный набор подфункций, описать требования к их производительности и удостовериться, что функциональная архитектура соответствует системным требованиям.
Определение подфункций
Функции декомпозируются в терминах их функциональных характеристик, состояний и режимов работы, временных параметров, условий потоков данных и потоков управления, режимов функциональных сбоев и их эффектов, и потенциальных функций отслеживания опасности, которые могут понадобиться. Альтернативных функциональные схемы и последовательности исследуются для обеспечения сбалансированного набора подфункций. Данное действие анализирует результирующую функциональную схему для определения степени дублирования. Выявленные дублирующие функции, которые не нужны для обеспечения безопасности, надежности или других критических требований, должны быть устранены. Данное действие позволяет выбрать лучшую функциональную архитектуру.
Определение состояний и режимов подфункций
Данное действие анализирует функциональную архитектуру для выявления и описания состояний и режимов, для которых подфункции предоставляют другое функциональное поведение. Анализ включает в себя преобразование состояния и режима между начальными и конечными условиями, или группировку подфункций.
Определение временных параметров функций
Данное действие анализирует последовательности подфункций и их функциональное поведение для выявления и определения функциональных временных параметров для каждого эксплуатационного сценария.
Определение потоков данных и потоков управления
Данное действие анализирует последовательности подфункций и их функциональное поведение для выявления и определения потоков данных между подфункциями для каждого эксплуатационного сценария. Эти потоки данных заносятся затем в диаграмму потоков данных.
Контроль выполнения функциональной архитектуры выявляется и определяется для каждого эксплуатационного сценария и, затем, заносится в диаграмму потоков управления.
Определение режимов сбоя функций и реакции на сбой
Данное действие анализирует и расставляет приоритеты потенциальным режимам сбоя функций для определения возможного эффекта сбоя и необходимости обнаружения отказов и функций восстановления.
Определение функций отслеживания опасности
Данное действие анализирует подфункции и группировки подфункций для выявления эксплуатационной опасности, которая может повлечь травмы, материальный ущерб или повреждение продукта, или вызвать негативное воздействие на окружающую среду. Здесь определяются функциональные требования для отслеживания опасных условий эксплуатации, или уведомления или предупреждения оператора о надвигающейся опасности.
2.4.4 Установка функциональной архитектуры
Данное действие устанавливает функциональную архитектуру, приемлемую для уровня разработки, для определения более мелких функций и распределения рабочих характеристик по функциям. Из чего потом будет моделироваться конструкционное исполнение системы на операции «Дизайн-синтез». До этого функциональная архитектура должна быть проверена, чтобы удостовериться, что она соответствует подтвержденной основной версии требований.
Декомпозиция функциональных требований Интернет-системы:
Ф1. Предоставлять информацию по запросу
Ф1.1. Разбирать запрос пользователя
Ф1.1.1. Разбирать запрос на элементы для дальнейшей обработки
Ф1.1.2. Подключать необходимые модули
Ф1.1.3. Запускать необходимые модули и получать от них информацию для шаблона
Ф1.2. Выбирать информацию
Ф1.2.1. Выбирать структуру меню
Ф1.2.2. Выбирать информацию по поисковому запросу пользователя
Ф1.2.3. Выбирать контентную информацию
Ф1.2.4. Предоставлять доступ к БД
Ф1.3. Отображать информацию
Ф1.3.1. Отображать отобранную информацию
Ф1.3.1.1. Заполнять шаблон данными
Ф1.3.1.2. Отображать заполненный шаблон
Ф1.3.2. Отображать кэшированную информацию
Ф1.4. Кэшировать информацию для последующего отображения
Ф2. Управлять содержанием и структурой информации
Ф2.1. Разбирать запрос пользователя
Ф2.1.1. Разбирать запрос на элементы для дальнейшей обработки
Ф2.1.2. Подключать необходимые модули
Ф2.1.3. Запускать необходимые модули
Ф2.2. Добавлять информацию
Ф2.2.1. Добавлять текст
Ф2.2.2. Добавлять графику
Ф2.2.3. Добавлять файлы
Ф2.2.3.1. Загружать файлы с компьютера пользователя
Ф2.2.3.2. Загружать файлы из Интернет
Ф2.3. Удалять информацию
Ф2.3.1. Удалять текст
Ф2.3.2. Удалять графику
Ф2.3.3. Удалять файлы
Ф2.4. Изменить информацию
Ф2.4.1. Изменять текст
Ф2.4.2. Изменять графику
Ф2.4.3. Переименовывать файлы
Ф2.5. Предоставлять доступ к информации
Ф2.5.1. Отображать навигацию
Ф2.5.2. Отображать информацию, которой нужно управлять
Ф2.5.2.1. Заполнять шаблон данными
Ф2.5.2.2. Отображать заполненный шаблон
Ф2.5.3. Предоставлять доступ к БД
Ф3. Обеспечивать защиту информации от несанкционированного изменения и удаления
Ф3.1. Авторизовать администратора
Ф3.2. Управлять администраторами
Ф3.2.1. Добавлять администратора
Ф3.2.2. Удалять администратора
Ф3.2.3. Изменить информацию об администраторе
Ф3.2.4. Менять уровень доступа администратора
Ф3.2.4.1. Управлять группами администраторов
Ф3.2.4.1.1. Добавлять группу
Ф3.2.4.1.2. Удалять группу
Ф3.2.4.1.3. Изменить название группы
Ф3.2.4.1.4. Назначить права группе
Ф3.2.4.2. Назначать администратора в группу
Ф4. Обеспечивать защиту информации от потери
Ф4.1. Создавать резервную копию информации
Ф4.2. Восстанавливать информацию из резервной копии
Ф5. Оформлять предоставляемую информацию
2.5 Проверка функциональной архитектуры
Цель процедуры - проверить функциональную архитектуру.
Задачей процедуры являются проверка функциональной архитектуры на предмет соответствия основной версии требований.
2.5.1Состав процедуры
Процедуры состоит из следующих операций:
· Определение процедур проверки
· Проведение проверочной оценки
o Проверка завершенности архитектуры
o Проверка функциональных показателей и рабочих параметров
o Проверка удовлетворения ограничениям
· Выявление расхождений и конфликтов
· Установка проверенной функциональной архитектуры
Структурная схема процедуры представлена на рис. 2.5.
Рис. 2.5 Структурная схема процедуры «Проверка функциональной архитектуры»
2.5.2 Определение процедур проверки
Установить процедуры проведения проверки функциональной архитектуры.
2.5.3 Проведение проверочной оценки
Проверка завершенности архитектуры
Данное действие проверяет, что все эксплуатационные требования, включенные в основную версию требований, прослеживаемы до установленной функциональной архитектуры.
Проверка функциональных показателей и рабочих параметров
Данное действие проверяет, что все функциональные требования и требования к рабочим характеристикам уровня системы основной версии требований прослеживаемы до установленной функциональной архитектуры.
Проверка удовлетворения ограничениям
Данное действие проверяет, что все процедурные, методические, функциональные физические ограничения и ограничения стандартизации основной версии требований прослеживаемы до установленной функциональной архитектуры.
2.5.4 Выявление расхождений и конфликтов
Выявляются все упущения, расхождения и конфликты в результате предыдущей операции. Когда выявлена неполнота функциональной архитектуры, выполняются операции процедуры функциональный анализ до тех пор, пока все упущения не будут исправлены.
Когда требования функциональной архитектуры не прослеживаются до подтвержденной основной версии требований, возможно в процессе функционального анализа были введены ненужные функциональные требований и/или требования к рабочим характеристикам, или были введены правильные функциональные требований и/или требования к рабочим характеристикам, и она должны быть отражены в основной версии требований. После последнего расхождения или конфликта процедуры Анализ требований и Подтверждение требований должны быть выполнены повторно для выпуска новой подтвержденной основной версии требований.
2.5.5 Установка проверенной функциональной архитектуры
Функциональная архитектура является проверенной после успешного выполнения проверочной оценки. Проверенная функциональная архитектура, с обоснованной структурой, стоимостными оценками, ключевыми решениями, документируется в обобщенной базе данных. Эта проверенная функциональная архитектура используется во время Дизайн синтеза для порождения физической архитектуры системы, удовлетворяющей ожидания заказчика и критериям приемки, описанным в основной версии требований.
2.6 Дизайн синтез
Рис. 2.6 Структурная схема процедуры «Дизайн синтез»
Цель процедуры - определение конструктивного исполнения системы, удовлетворяющего основной версии требований.
Дизайн-синтез преобразовывает функциональную архитектуру в физическую, которая показывает схему расположения элементов, их декомпозицию, внешние и внутренние интерфейсы, физические ограничения и конструктивные решения. Операции с 2.6.2 по 2.6.15 включают в себя выбор предпочтительного решения или схемы расположения из набора альтернативных вариантов, и обоснование связанной с каждым вариантом стоимости, графика разработки, эффективности и последствий риска. Процедура системный анализ используется в качестве необходимой вспомогательной процедуры для выбора альтернативных решений, для выявления, оценки, подсчета риска, и выбора соответствующего способа управления им, и для понимания стоимости, графика, эффективности выбора каждого альтернативного решения.
2.6.1 Состав процедуры
Процедура состоит из следующих операций:
· Группировка и выделение функций
· Выявление альтернативных конструкционных решений
· Оценка надежности, опасности вредного воздействия окружающей среды
· Оценка факторов качества жизненного цикла
· Оценка требований к технологии
· Выделение физических и рабочих характеристик
· Определение физических интерфейсов
· Оценка возможности использования стандартных элементов
· Оценка наличия стандартных элементов
· Оценка альтернативы «произвести или купить»
· Разработка моделей, изготовление прототипов
· Оценка видов отказов, их последствий и критичности
· Оценка необходимости тестирования
· Оценка возможности конструкции к доработке
· Завершение конструирования
· Инициирование эволюционной разработки
· Изготовление чертежей и схем
· Установка физической архитектуры
Структурная схема процедуры представлена на рис. 2.6.
2.6.2 Группировка и выделение функций
Сгруппировать или разделить функции и подфункции проверенной функциональной архитектуры по логическим физическим элементам, представляющим собой продукт системы или подсистему. Функция или набор подфункций может быть назначена более чем одному элементу. Устанавливается и регистрируется прослеживаемость требований для того, чтобы удостовериться, что все функции функциональной архитектуры распределены по физическим элементам системы, а каждый физический элемент выполняет хотя бы одну функцию.
2.6.3 Выявление альтернативных конструкционных решений
Выявить альтернативные решения для физических элементов, полученных в 2.6.2. Эти альтернативные решения составляются из различных комбинаций аппаратного и программного обеспечения, материалов, данных, устройств, людей, служб и техник. Во время операций с 2.6.4 по 2.6.15 альтернативы и группировки альтернатив анализируются на предмет того, какая из них наилучшим способом удовлетворяет распределенным функциональным требованиям и требованиям к рабочим характеристикам, требованиям интерфейсов и ограничениям конструкции. Во время выполнения этих операций узко квалифицированные инженеры работают с инженерами-конструкторами для обеспечения требований надежности, доступности, ремонтопригодности, безопасности, секретности, живучести, электромагнитной совместимости и т.д.
Дополнительно выявляются требования к процессу жизненного цикла системы для различных альтернативных решений и группировок этих решений.
2.6.4 Оценка надежности, опасности вредного воздействия окружающей среды
Анализировать альтернативные физические решения и группировки решений действия 2.6.3 для выявления потенциальной опасности для системы, ее операторов или окружающей среде.
2.6.5 Оценка факторов качества жизненного цикла
Оценить альтернативы, полученные в 2.6.3 на предмет степени реализации факторов качества жизненного цикла (возможность произвести, тестируемость, легкость распространения, пригодность к эксплуатации, поддерживаемость, обучаемость, размещаемость). Дополнительно оценить, определены ли и описаны связанные с процессом ЖЦ потребности, требования и ограничения.
2.6.6 Оценка требований к технологии
Оценить альтернативные варианты, полученные в 2.6.3 для выявления технологических потребностей, необходимых для того, чтобы сделать данное решение эффективным.
Определить и описать риск, связанный с применением новых или усовершенствованных технологий.
2.6.7 Выделение физических и рабочих характеристик
Выявить и документировать физические и рабочие характеристики альтернатив действия 2.6.3.
Выявить и описать физические характеристики и человеческий фактор, связанные с факторами качества жизненного цикла.
...Подобные документы
Реализация задачи использования методики SDLC (управление жизненным циклом разработки программного обеспечения) при внедрении реальной системы информационных технологий. Описание проекта внедрения системы автоматической регистрации участников выставок.
реферат [585,1 K], добавлен 10.09.2010Понятие программного обеспечения, вопросы его разработки и использования. Общая характеристика системного программного обеспечения и работа операционной системы. Специфика процесса управления разработкой программного обеспечения и его особенности.
курсовая работа [636,2 K], добавлен 23.08.2011Использование моделирования в программной инженерии в процессе разработки программного обеспечения. Основные этапы процесса разработки программного обеспечения, их характеристика. Моделирование процессов, их определение фазами и видами деятельности.
реферат [2,2 M], добавлен 25.12.2017Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
презентация [114,7 K], добавлен 14.08.2013Порядок автоматизации расчетов себестоимости и длительности программного обеспечения производственного предприятия. Выбор языка программирования и системы управления базами данных. Разработка алгоритмов расчета себестоимости программного обеспечения.
дипломная работа [1,7 M], добавлен 13.06.2017Понятие программного обеспечения; исследование достижений и перспектив развития информационных технологий и систем. Функциональная и структурная организация ЭВМ. Оценка эффективности программ, используемых в организации ООО "Крепость-Абакан", их анализ.
отчет по практике [76,8 K], добавлен 21.03.2013Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.
курсовая работа [97,7 K], добавлен 14.12.2012Понятие и специфика автоматизированных систем. Описание методики разработки программы для автоматизации. Ее тестирование и отладка. Внедрение АС в работу предприятия. Расчет экономического эффекта от разработки и реализации программного продукта.
дипломная работа [1,4 M], добавлен 23.06.2015Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.
курсовая работа [67,9 K], добавлен 29.05.2013Несоответствие процессов разработки программного обеспечения международным стандартам. Фазы, развитие вычислительной инфраструктуры. История развития компьютерных систем. Этапы разработки программ и их тестирование. Ошибки в программном обеспечении.
реферат [176,2 K], добавлен 27.08.2009Технология конструирования программного обеспечения, надежно и эффективно работающего в реальных компьютерах. Модель быстрой разработки приложений (Rapid Application Development) как один из примеров применения инкрементной стратегии конструирования.
реферат [666,5 K], добавлен 24.06.2009Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
дипломная работа [101,2 K], добавлен 17.06.2011Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Организационно-правовая форма предприятия. Ресурсы предприятия, эффективность их использования. Информационное обеспечение экономической работы организации. Оплата труда на предприятии. Организация рабочих мест. Собственные разработки программиста.
отчет по практике [59,5 K], добавлен 07.08.2013Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.
дипломная работа [2,3 M], добавлен 13.07.2011Сущность и значение средств управления базами данных предприятия. Методика разработки базы данных и прикладного программного обеспечения автобусного парка, позволяющее структурировать информацию об автобусных маршрутах, остановках и автобусах парка.
курсовая работа [163,4 K], добавлен 20.01.2010Классификация служебных программных средств. Файловая структура операционных систем. Основы графического интерфейса пользователя Windows XX. Анализ алгоритмов решения задач. Описание процесса разработки программного обеспечения и результатов работы.
курсовая работа [2,4 M], добавлен 14.11.2016Методологии разработки информационных систем в отечественной и зарубежной литературе. Государственные и международные стандарты в области разработки программного обеспечения. Разработка фрагмента информационной системы "Учебно-методический ресурс".
курсовая работа [364,6 K], добавлен 28.05.2009Порядок проектирования и разработки базы данных и программного обеспечения. Информация о структуре базы данных, созданных таблицах, формах, отчетах, запросах, хранимой информации. Логическая и концептуальная модели данных; выбор программного обеспечения.
курсовая работа [906,6 K], добавлен 20.01.2010Разработка базы данных для нужд предприятия ОАО "Металлист". Характеристика предприятия и его структурных подразделений. Отдел информационных технологий. Перечень и общая характеристика прикладного программного обеспечения, используемого в подразделениях.
отчет по практике [401,0 K], добавлен 17.01.2009
