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

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

Жизненный цикл программного средства.

Жизненный цикл программного средства. - раздел Государство, по Технологии Разработки Программного Обеспечения.   Под Жизненным Циклом Пс Понимают Весь Период Его Разработки И...

 

Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [1 - 4]. Жизненный цикл включает все процессы создания и использования ПС (software process). Различают следующие стадии жизненного цикла ПС (см. рис. 1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.

 

.

Разработка начинается с выработки требований к ПИ. На эту фазу приходится, как правило, 50% стоимости и 32% трудозатрат.

Фаза использования начинается с того момента, как изделие передается пользователю.

На этой фазе обычно выполняется обучение персонала, внедрение и настройка.

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

Процесс сопровождения продолжается параллельно эксплуатации ПИ. На расширение функциональных возможностей ПИ – 78% времени, на выявление ошибок – 17%. Обучение расширенным возможностям – 5%.

Но жизненный цикл ПИ имеет особенности, от жизненного цикла продукции производственно-технического назначения.

Особенности эти проявляются на этапах создания и эксплуатации.

Приведем это в форме таблицы.

 

Наименование этапов Содержание работы
Производственно-техническое назначение ПИ
1. Разработка Определение требований пользователя. Определение конструктивных элементов. Проектирование элементов. Изготовление опытного образца и его испытания. Создание технологии массового производства. -----//-----   -----//-----   -----//----- реализация и тестирование __________
2. Ввод в эксплуатацию Массовое производство копирование
3. Эксплуатация и обслуживание Постановка пользователю.
Техническое обслуживание (ремонт). Возвращение изделия на доработку. Расширение функциональных возможностей. ___________ сопровождение сопровождение
4. Снятие с эксплуатации Физический износ Моральный износ __________ -----//-----

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

Начальный этап проектирования ПИ состоит из следующих процессов:

1. Анализ и разработка требований к ПИ.

2. Определение целей создания ПИ.

3. Разработка внешних спецификаций проекта.

I процесс.

В процессе разработки требований необходимо решить следующие задачи:

а) выявить наличие информации, необходимой для выполнения планируемых функций;

б) определить трудоемкость и стоимость предстоящей работы;

в) обеспечить полноту и точность определения функций, подлежащих выполнению ПИ, их взаимосвязь;

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

Необходимо делать различия между жесткими требованиями и требованиями, которые не являются строго обязательными.

Можно установить две фазы в выработке требований.

1-ая фаза планирования, на которой в процессе взаимодействия пользователей и разработчиков определяется реализуемость (можно ли реализовать требования), устанавливаются цели (что должна делать программа), оцениваются затраты и обеспечивается ориентация для разработки проекта (ориентация на какой-либо пакет или новый компьютер).

2-ая фаза выработки требований пользователя. На этой фазе вырабатываются требования к входным данным, информационным потокам, выходным данным, документации, среде, вычислительным ресурсам.

Результатом работы по выработке требований обычно является соответствующий документ, который должен быть: достаточным для реализации целей ПИ, достаточно полным, чтобы в дальнейшем исключить серьезные модификации ПИ, достаточно простым и понятным для просмотра и утверждения администрацией.

Требования являются определенными в том объеме, в котором они фиксируются в документации.

За полноту и точность сформулированных требований к ПИ отвечает пользователь. Проектировщик отвечает за качество описания требований и их реализуемость.

II процесс. Разработка и описание целей (т.е. процесс разработки в проектировании).

На этом этапе устанавливаются взаимосогласованные цели создания ПИ. Это связано с тем, что некоторые цели имеют противоречивый характер, и необходимо найти компромиссное решение: установить, какие из них более важны при разработке ПИ, а какими можно пренебречь.

При описании целей возможно возникновение следующих ошибок:

1. Противоречивость в описании сформулированных целей;

2. Наличие поверхностно выявленных целей, не отражающих специфических особенностей разрабатываемого ПИ (например, зарплата);

3. Цели создания ПИ с точки зрения пользователя (цели продукта) и цели проекта (с точки зрения проектировщика) противоречивы (т.е. несогласованность разработки и пользователя).

Цели ПИ, рассматриваемые с точки зрения пользователей, обычно включают следующую информацию.

1. Краткое описание. В нем кратко определяется общее назначение разрабатываемого ПИ и его функций.

2. Определение пользователя. Описывается круг возможных пользователей, характеризуются специфические особенности отдельных групп пользователей (Кто будет пользоваться? Чем эти пользователи отличаются?).

3. Подробное описание функциональных задач. Оно характеризует однозначное восприятие требований пользователей – разработчиков.

4. Документация – определяются состав документов, выдаваемый каждому пользователю.

5. Эффективность. Описываются все цели, касающиеся производительности: временные характеристики, пропускная способность, использование ресурсов и т.д.

6. Совместимость. Указываются стандарты, которым необходимо следовать в процессе разработки, а также другие программные продукты, с которыми разрабатываемое ПИ должно быть совместимо.

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

8. Безопасность. Формируются цели в отношении обеспечения безопасности ПИ (сохранение информации, пароль, гриф секретно).

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

10. Установка. Описываются методы и средства настройки ПИ на конкретные условия эксплуатации (требования на ограничения по настройке, разделение на 5 человек).

11. Надежность. Цели по достижению надежности в значительной мере зависят от конкретного типа разрабатываемого ПИ. Но можно определить некоторые общие вопросы, которые должны быть рассмотрены:

а) среднее время наработки на сбой для каждого вида сбоя (ПИ, пользователь, отдельная функция) и степень важности сбоя (для ПО для систем реального времени);

б) среднее время восстановления ПИ после сбоя;

в) цели по числу ошибок ПИ по категориям сложности и время обнаружения;

г) последствия сбоев системы и наиболее важных функций;

д) допустимый объем данных, утрачиваемых во время сбоя и уровень обеспечения безопасности;

е) функции, необходимые для обнаружения и исправления ошибок, а также обеспечение устойчивости к ним;

ж) возможности обнаружения ошибок пользователя и аппаратуры, а также восстановления работоспособности.

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

Цели проекта должны быть ясными, обоснованными и измеримыми, а также известными как пользователям, так и разработчикам.

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

III процесс.Разработка внешних спецификаций проекта. Упрощенно – это разработка инструкций пользователю.

При их написании разработчик должен решить три проблемы:

1. Доведение до минимума ошибок пользователя;

2. Обнаружение ошибок пользователя в случае их возникновения;

3. Доведение до минимума сложности разрабатываемого программного изделия.

Разработка внешних спецификаций разбивается на 2 части:

1. Предварительный внешний проект.

2. Детальный внешний проект.

Предварительный внешний проект содержит описание функций по составляющим компонентам ПИ (Решить какие функции необходимо описать в инструкции).

Детальный внешний проект каждой функции пользователя должен содержать следующую информацию:

1. Описание входных данных;

2. Описание выходных данных;

3. Преобразование системы (например, обновление массива начисления и удержания по заработной плате после расчета за месяц, при перерасчете. Оно должно быть написано с точки зрения пользователя);

4. Характеристика надежности. Описывается влияние всех возможных отказов функции на систему.

5. Эффективность. Описываются все ограничения (память, время и т.д.).

 

При завершении этапа внешнего проектирования необходимо все проанализировать на точность и полноту изложенного, так как на этом этапе значительно легче внести изменения, чем на этапе внутреннего проектирования.

 

 

Процессы ЖЦ ПО: (по стандарту 12207)

 

 

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

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

по Технологии Разработки Программного Обеспечения.

На сайте allrefs.net читайте: по Технологии Разработки Программного Обеспечения....

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

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

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

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

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

Описание предметной области.
Каждый автомобиль характеризуется следующими параметрами: o регистрационный номер автомобиля; o номер автомобиля; o Марка автомобиля; o Цвет; o Состояни

Формальные модели предметной области
Прокат автомобилей [1] Сбор заявок [1.1] Прием заявок [1.1.1] Анализ заявок [1.1.2] Сохранение заявок [1.1.3] Сбор сведений о клиенте [1.2] Прием информации о клиенте [1.2.1

С) 3 уровень
1) Сбор заявок 2) Сбор сведений о клиенте

Описание, постановка задачи и разработка бизнес-правил.
Фирма «АВТАННА» занимается прокатом легковых автомобилей.   Процесс проката осуществляется следующим образом. Клиент производит заказ на прокат желаемого авт

ОПИСАНИЕ ЗАДАЧИ.
Наименование задачи: Автоматизация управления работой дилера по прокату легковых автомобилей   Цель работы дилера: Прокат легковых автомобилей

II. Основание для разработки
§ Основание для разработки Основанием для разработки текстового редактора является задание на курсовой проект по дисциплине “Технология разработки программного обеспечения”.

IV. Требования к программе и программному изделию
§ Требования к составу АИСК должна состоять из одного модуля, выполняющего все требуемые функции. § Требования к функциональным характеристикам Требования к

Требования к составу выполняемых функций
    § Условия эксплуатации АИСК должен функционировать в соответствии с заданными в настоящем ТЗ тре­бованиями, в составе ПО ПЭВМ, при эксплуатации ПЭВМ.

V. Требования к программной документации
§ Требования к составу документации Состав документации определяется Исполнителем на этапе разработки переч­нем разрабатываемых документов и согласовывается с Заказчиком. В

VIII. Порядок контроля и приемки
Приемка разработанного АИСК осуществляется на средствах вычислительной техники Заказчика в объеме, определяемом программой и методикой испытаний АИСК, и в сроки, определенные ведомостью исполнения

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

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

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

Реляционная модель данных
  Понятие реляционный (англ. relation — отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда. Эти модели харак

Инфологическое моделирование.
Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по БД. И это описание должно быть настолько ёмким, чт

База данных автомобилей
Name Code Type I M Регистрационный номер автомобиля REG_AVTO I Ye

Переход к реляционной модели данных.
Инфологическая модель используется на ранних стадиях разработки проекта. Если понимать язык условных обозначений, которые соответствуют категориям ER-модели, то её можно легко «читать», следователь

Словарь данных.
Управленческим инструментарием разработки при проектировании БД является словарь данных (СД). Внедрение БД на любом предприятии занимает довольно продолжительное время. Её расширение проис

Процесс программирования.
  1) Краткая характеристика программного обеспечения, используемого при создании СУБД.   Рассмотрим более подробно программные продукты компании Micros

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА, РЕАЛИЗУЮЩИЕ МЕТОДЫ СЕТЕВОГО ПЛАНИРОВАНИЯ И УПРАВЛЕНИЯ.
  Внедрение систем управления проектом в организации сегодня перестало быть лишь средством повышения эффективности существующей системы управления. Постоянное совершенствование методо

Календарный план реализации проекта
№ Наименование работ   Номера этапа Сроки Анализ предметной области, анализ требований к си

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