Основные процессы жизненного цикла

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

РаРаРР

готовый ПП передается в эксплуатацию и сопровождается. Все перечисленные процессы относят к главным процессам ЖК ПП.

Процесс приобретения(acquisition process)охватывает действия клиента по приобретению ПП. К этим действиям относятся:

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

Инициирование приобретения включает в себя следующие задачи:

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

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

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

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

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

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

корректировка и Подготовка контракта включают в себя следующие задачи:

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

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

В ходе приемки готовятся и выполняются нужные тесты. Завершение работ по договору осуществляется вслучае удовлетворения всем условиям приемки.

Процесс поставки(supply process)охватывает задачи и действия поставщика при снабжении клиента ПП либо услугой. К этим действиям относятся:

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

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

Подготовка ответа на заявочные предложения выполняется в соответствии с принятыми ответами в следствии инициирования поставки.

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

Планирование выполняется по окончании заключения контракта и включает в себя следующие задачи:

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

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

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

оценка и Проверка выполняются в соответствии с действиями, предусмотренными в процессах совместной аудита и оценки.

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

Процесс разработки(development process)охватывает задачи и действия разработчика и предусматривает следующие главные направления работ:

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

Разглядим список работ процесса разработки более детально.

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

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

Существуют два варианта неопределенности:

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

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

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

Во втором случае определяют:

• взаимосвязи и структуру автоматизируемых информационных процессов;

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

• функции ПО; внешние условия его особенности и функционирования его интерфейсов, как с пользователями, так и при необходимости – с аппаратной частью;

• требования к программным и информационным компонентам, нужные аппаратные ресурсы, требования к базам данных и физические характеристики программных компонент.

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

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

Факторами, определяющими характеристики разрабатываемого ПО, являются:

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

• среда функционирования (программная и аппаратная) – возможно задана, быть может выбираться для обеспечения параметров, указанных в техническом задании;

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

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

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

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к оформлению и содержанию». В соответствии с этим стандартом техническое задание должно содержать следующие разделы:

• введение;

• основания для разработки;

• назначение разработки;

• требования к программе либо программному изделию;

• требования к программной документации;

технико-экономические показатели;

• стадии и этапы разработки;

• приёмки и порядок контроля.

Формальная постановка задачи. Задача возможно представлена в виде уравнений, соотношений, ограничений и т. д. Наряду с этим она представляется математической моделью. Кое-какие задачи, решаемые на данный момент на ЭВМ, не допускают и не требуют математической постановки (к примеру, задачи обработки текстов).

Процесс построения математической таковой модели включает:

• анализ условия задачи;

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

• формальную постановку задачи;

• определение способа преобразования данных в итог, т. е. способа ответа задачи.

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

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

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

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

• требования к итогам (допустимую погрешность);

• характеристики способа (правильный либо приближенный, погрешности результатов, вычислительную и емкостную сложности, сложность реализации и т. п.).

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

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

Виды архитектур уже рассматривались выше.

Тип интерфейса пользователя во многом определяет трудоёмкость и сложность разработки. По последним данным до 80 % кода программы может реализовывать как раз интерфейс пользователя. Виды интерфейса пользователя будут рассмотрены раздельно.

Как правило никакой неприятности выбора языка программирования реально не существует. Язык возможно выяснен:

• организацией, ведущей разработку; к примеру, в случае если компания обладает лицензионным вариантом C++ Builder, то она будет вести разработки в основном в данной среде;

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

• устоявшимся мнением («все разработки подобного рода должны быть выполнены на C++ либо на Java либо на …») и т. п,

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

• универсальные языки большого уровня;

• специальные языки разработчика ПО;

• специальные языки пользователя;

• языки низкого уровня.

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

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

Чаще всего применяемыми являются визуальные среды Delphi, C++ Builder компании Borland (ЖД Corporation), Visual C++, Visual Basic компании Микрософт, Visual Ada компании IBM и др.

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

• стандарт проектирования;

• стандарт оформления проектной документации;

• стандарт интерфейса пользователя.

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

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

Функциональная схема либо схема данных (ГОСТ 19.701-90) – схема сотрудничества компонентов ПО с описанием информационных потоков, состава данных в потоках и указанием применяемых устройств и файлов. Функциональные схемы, более информативны, чем структурные. Для изображения функциональных схем применяют особые обозначения, установленные стандартом. Главные обозначения схем данных по ГОСТ 19.701-90 приведены в табл. 5.1.

Жизненный цикл разработки ПО. Каскадная и итеративная модели жизненного цикла ПО

Похожие статьи:

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock
detector