В россии международным стандартам серии исо 9000 (iso 9000) соответствует следующие национальные стандарты

Скачать 1.45 Mb.

Название	В россии международным стандартам серии исо 9000 (iso 9000) соответствует следующие национальные стандарты
страница	8/13
Дата публикации	05.09.2014
Размер	1.45 Mb.
Тип	Документы

100-bal.ru > Информатика > Документы

1 ... 5 6 7 8 9 10 11 12 13

Шаги процесса[править | править исходный текст]

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

Модели процесса[править | править исходный текст]

Модель водопада (Каскадная модель)
- структурное проектирование
- тестирование программ
- сертификация программ
Итеративный процесс
- Гибкие методологии разработки
- Экстремальное программирование
Формальные методы
- логическое программирование
- доказательное программирование

- сопроводительные процессы разработки программного обеспечения;

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

1. Процесс документирования. Определяет действия для записи информации, происходящие во время жизненного цикла.

2. Процесс управления конфигурацией. Определяет действия по управлению конфигурацией.

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

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

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

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

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

8. Процесс разрешения проблем. Определяет действия для анализа и устранения проблем (включая несогласие), природа или источник которых обнаружены в течение разработки, эксплуатации, сопровождения или других процессов.

- организационные процессы разработки программного обеспечения;

Организационные процессы. Раздел 7 ИСО/МЭК 12207-95 состоит из четырех процессов. Они используются организацией на верхнем уровне для установления, выполнения и усовершенствовании структуры нижнего уровня, построенной на связи процессов жизненного цикла и персонала организации. Обычно они используются вне сферы конкретных проектов и контрактов; однако уроки, извлеченные из этих проектов и контрактов, способствуют усовершенствованию организации. Организационные процессы:

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

2. Процесс инфраструктуры. Определяет основные действия на установления нижележащей структуры процесса.

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

4. Процесс обучения. Определяет действия по обеспечению соответственно подготовленного персонала

- процесс приобретение;

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

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

- процесс поставки;

2. Процесс поставки. Определяет действия поставщика, организации, предоставляющей программный продукт заказчику.

инициирование поставки;
подготовку ответа на заявочные действия;
подготовку договора;
планирование;
выполнение и контроль;
проверку и оценку;
поставку и завершение работ.

- процесс разработки программного обеспечения

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

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

- процесс эксплуатации;

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

подготовительную работу;
эксплуатационное тестирование;
поддержку пользователей.

- процесс сопровождения.

5. Процесс сопровождения. Определяет действия сопровождающего, организации, предоставляющей услуги по сопровождению программного обеспечения; т.е., управлению изменениями в программном обеспечении для поддержки его в актуальном и работоспособном состоянии. Этот процесс включает перемещение и отставку программного обеспечения.

подготовительную работу;
анализ проблем и запросов на модификацию программного обеспечения;
модификацию программного обеспечения;
проверку и приемку;
перенос программного обеспечения в другую среду;
снятие программного обеспечения с эксплуатации.

9 Процесс разработки программного обеспечения

- виды деятельности процесса разработки программного обеспечения;

Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектомвыполняется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.

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

Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называютсярабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

- инструментарий процесса;

Какие либо действия , типо качества обработки чистка

- анализ системных требований;

Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.

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

Анализ требований включает три типа деятельности:

Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.
Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.
Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.

Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков. Новые системы изменяют окружающую среду и отношения между людьми, таким образом важно определить все заинтересованные лица, принять во внимание все их потребности и гарантировать, что они понимают значения новых систем. Аналитики могут использовать несколько методов, чтобы выявить требования от клиента такие, как проведение интервью, или использование фокус-групп и создание списков требований. Более современные методы включают создание прототипов и сценариев использования. Где необходимо, аналитик будет использовать комбинацию этих методов, чтобы выявить точные требования заинтересованных лиц, таким образом, чтобы была создана система, которая удовлетворяет деловые потребности.
- системное проектирование;

Системное проектирование[править | править исходный текст]

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

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

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

Основные части проектирования

Принципы системного проектирования[править | править исходный текст]

Системное проектирование должно базироваться на системном подходе. На сегодняшний день нельзя утверждать, что известен его полный состав и содержание применительно к проектной деятельности, однако можно сформулировать наиболее важные из них:

Практическая полезность:
- деятельность должна быть целенаправленной, устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной групп людей;
- деятельность должна быть целесообразной. Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на решении главных задач;
- деятельность должна быть обоснованной и эффективной. Разумным будет использование не любого решения задачи, а поиск оптимального варианта;
Единство составных частей:
- целесообразно любой объект, сложный ли он или простой, рассматривать как систему, внутри которой можно выделить логически связанные более простые части —подсистемы, единство частных свойств которых и образует качественно новые свойства объекта-системы;
- разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
- внешняя, или как её ещё называют — жизненная среда, также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
Изменяемость во времени:
- учёт этапов жизненного цикла объекта;
- учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки.

- анализ требований к программному обеспечению;

Процесс работы с требованиями к продукту можно разделить на 4 этапа:

 Определение концепции продукта.

 Сбор требований.

 Анализ требований.

 Проектирование системы

Определение концепции продукта

На этапе определения концепции продукта, проводится работа с его инвестором,

целью которой является выработка единого видения будущего продукта. По окончанию

этого этапа производится вывод о том, будет ли этот продукт разрабатываться или нет.

Сбор требований

На этапе сбора требований основная работа ведется с заказчиком системы и еѐ бу-

дущими пользователями. Цель этапа — точно определить функции продукта и способы

его интеграции в существующие процессы.

Качественное выполнение работ на этом этапе гарантирует то, что будущий про-

дукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обес-

печивает реализацию наиболее востребованной функциональности и исключение второ-

степенной/невостребованной функциональности, что сэкономит бюджет и сроки.

Анализ требований

На этапе анализа требований проходит структуризация уже собранных ранее тре-

бований. Цель этапа — предоставить четкий список не дублируемых требований

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

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

Правильно сгруппированные требования помогут обойтись минимальным количе-

ством функционала для удовлетворения максимально большего количества целей, а это,

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

Проектирование системы

Целью всех предыдущих этапов был сбор информации о том, кому и зачем необхо-

дим будущий продукт. Этап проектирования — это первый этап, на котором группа раз-

работки принимает проектные решения о том, какую функциональность будет нести про-

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

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

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

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

В зависимости от класса создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации — блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат:

Архитектура ПО;
Устройство компонентов ПО;
Пользовательские интерфейсы.

В российской практике проектирование ведется поэтапно в соответствии со стадиями, регламентированными ГОСТ 2.103-68: Техническое задание, Техническое предложение, Эскизный проект, Технический проект, Рабочий проект.^[1] На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).
В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document.
- детальное проектирование программного обеспечения;

Цель детального проектирования (называемого также разработкой исполнительного проекта) — опираясь на результаты и решения эскизного проектирования, осуществить детальную проработку проблем вплоть до обеспечения такого уровня решения проекта, который свидетельствует о его окончательной готовности к реализации. Для этого данные и содержательную сторону решений следует перепроверить, дополнить, уточнить, а при необходимости значительно расширить.

Для этого при детальном проектировании необходимо обратить внимание на такие, например, подробности, как:

• расстановка рабочей силы по рабочим и производственным операциям;

• подготовка и обработка груза заготовок (палет);

• требования к освещенности, шумности и климатическим условиям;

• обеспечение техники безопасности и противопожарной защиты;

• размещение оборудования, обеспечивающее удобные условия для управления, ремонта и обслуживания;

• интеграция информационно-коммуникационного оборудования.
- программирование и отладка;

Отла́дка — этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится:

узнавать текущие значения переменных;
выяснять, по какому пути выполнялась программа.

Существуют две взаимодополняющие технологии отладки.

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

Инструменты отладки[править | править исходный текст]

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

Также полезными инструментами в руках программиста могут оказаться:

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

Использование языков программирования высокого уровня, таких как Java, обычно упрощает отладку, поскольку содержат такие средства как обработка исключений, сильно облегчающие поиск источника проблемы. В некоторых низкоуровневых языках, таких как ассемблер, ошибки могут приводить к незаметным проблемам — например, повреждениям памяти или утечкам памяти, и бывает довольно трудно определить что стало первоначальной причиной ошибки. В этих случаях, могут потребоваться изощрённые приёмы и средства отладки.
- интеграция программного обеспечения;

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

Непрерывная интеграция является одним из основных приёмов экстремального программирования.

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