41. Процессы жизненного цикла программного средства, определяемые в стандарте гост p исо/мэк 12207.

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

Вспомогательные процессы жизненного цикла программного средства

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

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

В стандарте ГОСТ Р ИСО/МЭК 12207 впервые реализован принцип структурной стандартизации ЖЦ ПС на основе регла­ментации требований к процессам, работам и задачам, входящим в полную типовую структуру ЖЦ ПС.

Процессы ЖЦ ПС выделены по принципу ответственности субъекта (заказчика, поставщика, разработчика и т. д.), реализу­ющего конкретный процесс. В свою очередь, каждый из процес­сов состоит из ряда работ и решаемых при выполнении соответ­ствующей работы задач. С точки зрения соподчиненности и важ­ности данных процессов они разбиты на три группы: основные; вспомогательные; организационные (рис. 2.1).

Группа основных процессов включает в себя процессы: приоб­ретение; поставка; разработка; эксплуатация; сопровождение,

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

Группа организационных процессов включает в себя процес­сы: управление проектами; создание инфраструктуры проекта; определение, оценка и улучшение самого ЖЦ; обучение.

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

7. Фазы разработки и внедрения асоиу.

42. Фаза жизненного цикла АС «Обоснование». Поиск объекта автоматизации. Выяснение целесообразности создания АС и заключение предварительного соглашения. Формирование требований к АС и разработка концепции ее создания. Составление и согласование технического задания на АС. Заключение договора на создание АС.

1. Фаза «Обоснование»

Фаза «Обоснование» предваряют конструктивную (созидательную) деятельность по созданию АС.

Цели разработчика на этой фазе - найти заказчика создаваемой сис­темы и заключить с ним договор о создании АС на приемлемых для себя условиях.

Задачи потенциального заказчика:

• определение целесообразности реализации предлагаемого варианта АС,

• прогнозирование способности вы­полнить оговариваемый объем работ в согласованные сроки,

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

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

На фазе «Обоснование» разработчик и заказчик находятся на принци­пиально разных экономических позициях.

1. Для разработчика заключение каждого очередного договора - жизненная необходимость.

Для заказчика автоматизация обработки информации - всего лишь один из возможных способов совершенствования бизнес-процессов на предприятии.

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

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

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

1. Поиск объекта автоматизации

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

В качестве важнейших источников информации о потенциальных за­казчиках и их намерениях могут рассматриваться:

• объявления о конкурсах (тендерах;

• публикации в периодической печати;

• пресс-релизы о пер­спективных планах руководства предприятия;

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

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

• экспонирование своих услуг и результатов на специализированных выставках и конференциях.

• Рекомендации коллег, ответственных работников, авторитетных специалистов обладающих позитивным опытом дело­вого сотрудничества с этим разработчиком.

Значительно менее полезной следует признать массовую рассылку писем с предложениями о со­трудничестве по почтовым адресам, Это «информационный шумом», спам, т. е. отправляет в мусорную корзину без рассмотрения.

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

• опыт предыдущих контактов;

• весомая рекомендации;

• активная рекламная кампания.

2. Выяснение целесообразности создания АС и заключение предварительного соглашения

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

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

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

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

Подтверждением серьезности намерений заказчика может считаться

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

3. Формирование требований к АС и разработка концепции ее создания

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

1. Какие цели рассматривают в качестве приоритетных руководители предприятия-заказчика и рядовые пользователи будущей АС?

2. Какие виды эффектов от внедрения АС для них наиболее важны?

3. Какие зна­чения показателей эффективности они склонны рассматривать как удовлетворительные?

4. Насколько готовы руководители предприятия и будущие пользователи АС к радикальным изменениям технологии обработки информации?

5. В каком состоянии находится информационная система предприятия?

6. Используются ли в ней современные информационные и коммуника­ционные технологии?

7. Насколько сложно будет адаптировать ее к функционированию в рамках АС?

8. Насколько полна и формализована нормативная (алгоритмическая) база обработки информации на предприятии? В какой степени (до ка­ких пределов) ее можно модифицировать и/или оптимизировать?

9. С какими системами должна взаимодействовать создаваемая АС?

10. Ка­кие требования предъявляют взаимодействующие системы к входным и выходным информационным потокам?

11. Каков уровень ИТ- компетентности и информационной культуры бу­дущих пользователей АС?

12. Насколько высока их готовность решать задачи в составе АС?

13. Какова степень унификации применяемых технологий обработки ин­формации и алгоритмов решения функциональных задач?

14. Насколько возможно и целесообразно создавать АС на базе существующих типо­вых проектных решений?

15. Какие оригинальные решения необходимо реализовать в создаваемой АС и какова их трудоемкость?

16. Какие работы в смежных областях (строительные, электротехниче­ские и т. п.) необходимо выполнить для подготовки объекта к внедре­нию АС и какова их трудоемкость?

17. Какие финансовые ресурсы потребуются заказчику для создания АС?

18. В какие сроки может быть создана и внедрена система?

Все требования, предъявляемые к АС, подразделяются на две катего­рии: общие требования и частные требования.

Общие требования предъявляются к любой автоматизированной системе независимо от ее масштаба, предметной области, автоматизи­руемых функций и других характеристик. В ГОСТ 24.104 выделены пять групп общих требований:

1. Требования к АС - общие требования, предъ­являемые как к АС в целом, к выполняемым функциям, персо­налу и конкретным видам обеспечения.

2. Требования безопасности - условия, выполнение ко­торых повысит безопасность персонала АС, а также снизить риск возникновения аварийных ситуаций.

3. Виды и порядок проведения испытаний при вводе АС в действие - описывают содержание, а также порядок и длительность выполнения процедур, подтверждающих работоспособность созданной АС и ее соот­ветствие обязательным и взаимно согласованным требованиям.

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

5. Гарантии - определяют минимальную длительность гарантийного обслуживания АС и правила исчисления гарантийного срока, а также

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

гарантийное обслуживание автоматизированной системы.

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

Частные требования не могут противоречить общим требованиям, подменять или ослаблять их. Согласно ГОСТ 24.104 гарантийный срок на АС не может быть менее 18 месяцев. Все обязательные к исполнению частные требования к автоматизированной системе должны фиксироваться в техническом задании на АС!

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

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

4. Составление и согласование технического задания на АС

Техническое задание (ТЗ) на АС - важнейший предпроектный документ, в котором определяются цели и назначение АС, а также перечисляются предъявляемые к ней требования.

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

На фазе «Создание» ТЗ используется разработчиком как нормативный документ, задающий «области допустимых значений» параметров АС, т. е. условия, обязательные для исполнения в процессе проектирования и реализации системы.

На фазе «Внедрение» ТЗ используется приемочной комиссией как эталон, с которым сравнивается предъявленный к вводу в действие вариант АС. Формальным условием приемки АС в эксплуата­цию считается ее полное соответствие всем требованиям технического задания, а также общим требованиям к автоматизированным системам. При положительных результатах предварительных и приемочных испы­таний и отсутствии отклонений от указанных требований приемочная комиссия принимает решение о вводе АС в действие.

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

• создание АС,

• развитие АС,

• модернизация АС.

Техническое задание на создание АС составляется в случае, когда информационная система объекта автоматизации (или той его части, ко­горая вызывает особый интерес заказчика и разработчика) функциониру­ет без применения современных информационных и коммуникационных технологий.

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

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

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

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

5. Заключение договора на создание АС

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

В договоре на создание АС в обязательном порядке определяются:

• стороны договора;

• представители заказчика и разработчика;

• предмет договора - название работы;

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

• обязательства сторон - подробное перечисление обязательств;

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

• срок действия договора;

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

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

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

• санкции за невыполнение и/или ненадлежащее выполнение обя­зательств по договору;

• форс-мажорные обстоятельства;

• адреса и реквизиты сторон;

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

■ дата подписания договора.

Наряду с техническим заданием на АС, календарным планом выпол­нения работ и протоколом соглашения о договорной цене (состав и со­держание договорной документации см. в гл. 5), к договору на создание АС могут прилагаться и другие документы, положения которых считают­ся сторонами обязательными для исполнения.

43. Фаза жизненного цикла АС «Создание». Приказ о начале работ

Дополнительное обследование объект автоматизации. Эскизное проектирование. Техническое проектирование. Реализация автоматизированной системы.