1. Общие принципы стандартизации жизненного цикла программных средств…
Общие принципы стандартизации ЖЦ программных средств
Обязательная реализация в ходе проекта типовых процессов ЖЦ (заказ, поставка, разработка, эксплуатация, сопровождение и т. д.) дает возм-сть исп-ть принципы и методы функц-льной стандартизации, основанные на применении базовых стандартов и разработанных на их осн профилей стандартовтов для конкр типа объекта (в наш случ — проекта или системы). Базовый стандарт - принятый нормативн док-т, регламент-щий типовые (возможно многовариантные) требования, нормы и правила применит-но к данн объекту стандартизации. Профиль стандарта - принятый нормативн док-т, регламент-щий тр-ния, нормы и правила, выбранные из базовых стандартов и при необх-ти доп-ные и/или уточненные применит-но к конкрет классиф-нной группе данног объекта стандартизации.
Осн принципы и методы создания профилей стандартов устан-ны в стандартах серии ГОСТ Р ИСО/МЭК ТО 10000. Применительно к ПС построение профилей стандартов активно применяется в междунар и национальной стандартизации. В России впервые основы построения и исп-я профилей стандартов ЖЦ ПС заложены принятием в кач-ве базового стандарта ГОСТ Р ИСО/МЭК 12207 «ИТ. Процессы ЖЦ ПО». Введен с 1 июля 2000 года.
Адаптация стандарта ГОСТ Р ИСО/МЭК 12207 к конкретному проекту
Применение треб-й ГОСТ Р ИСО/МЭК 12207 к конкр проекту (его адаптация) состоит из следующей последовательности действий: 1.опред-ие условий выполнения проекта; 2. запрос исходных данных для адаптации; 3. выбор процессов, работ и задач; 4. документир-е решений по адаптации и их обоснование.
1.При опредедении условий вып-я проекта д/б определены осн хар-ки проекта, влияющие на адаптацию (м-ль ЖЦ; влияние ЖЦ сущ-щей системы; тр-ния к системе и ПС; организ-ные подходы, процедуры и цели; размер, критичность и типы системы, ПС, продукта или услуги; кол-во задействованного персонала и участ-щих в проекте сторон).
2.При запросе исх данных для адаптации от уч-щих в проекте суб-тов должны быть запрошены и получены исх данные, могущие повлиять на решения по адаптации. В работы по адаптации должны быть вовлеч польз-ли, персонал сопровождения, заказчикк и потенц-ные поставщики.
3.При выборе процессов, работ и задачч д/б определены необх-ые для построения модели ЖЦ ПС процессы, работы и задачи. При этом д/б охвачены разрабатываемая док-ция и обязанности исполн-лей. Дополнительные процессы, работы и задачи, необх-ые для реализации проекта, но не описанные в 12207, следует устан-вать в договорной док-ции проекта.
4.Все решения по адаптации и их обоснования д/б документально оформлены.
При проведении раб-т по адаптации следует руководствоваться рекомендациями, приведенными в прилож к данному стандарту.
Процессы общей структуры ЖЦ ПС по 12207 основаны на 2 исходных принципах:
1.Пр-п модульности основан на следующих положениях: Кажд процесс сильно связан, т.е. организован т.о., что все части пр-са (работы, задачи) строго взаимоувязаны и Процессы свободно соединены м/ду собой. Кол-во интерфейсов между процессами сведено к минимуму.
2.Пр-п ответственности базируется на определенных обязанностях каждого субъекта, вовлеченного в ЖЦ. Субъект может выполнять один или несколько процессов. Процесс может быть выполнен одним или несколькими субъектами, при этом один из субъектов должен быть определен ответственным за процесс. Субъект, выполняющий процесс, несет ответственность за весь данный процесс, даже если выполнение отдельных работ поручено другим субъектам.
Применение 12207 требует от соответствующих субъектов определенных усилий по его адаптации к условиям реализации конкретных проектов, по его взаимоувязке с конкретными методиками разработки систем и другими стандартами. Внедрение данного стандарта в практическую деятельность должно облегчить упорядочение взаимоотношений между субъектами, вовлеченными в ЖЦ ПС.
Характеристики пр-сов ЖЦ ПС согласно ГОСТ Р ИСО/МЭК 12207
Основные процессы ЖЦ реализуются ответственным субъектом, вовлеченным в ЖЦ ПС. Ответ субъ-м явл одно из юрид.лиц (или подразделений, или должностных физических лиц), кот реализуют соотв-й процесс. Ответств субъ-ми может быть заказчик, поствщик, разработчикк, эксплуатационный (опер-р) и сопровождающий персонал. Осн процессы ЖЦ ПС: Процесс заказа; Процесс поставки; Процесс разработки; Процесс эксплуатации; Процесс сопровождения.
Вспомогательные процессы явл составгой частью др процессов, обесп-щей успешную реализацию и кач-во вып-ния проекта. Конкр вспом-й процесс при необх-ти инициируется и исп-ся др процессом. Всопомогательный процессы: Процесс документирования; Процесс управления конфигурацией; Процесс обеспечения качества; Процесс верификации; Процесс аттестации; Процесс совместного анализа; Процесс аудита; Процесс решения проблем.
Организ-е процессы ЖЦ применяются каким-л субъ-том для создания и реализации осн структуры модели ЖЦ ПС, охват-щей взаимосв-ые процессы и соотв-щий персонал, а также для постоянного совершенствования данной структуры и входящих в нее процессов. Организационные процессы, как правило, являются типовыми независимо от области выполнения конкр проектов и договоров. Перечислим: Процесс управления; Процесс создания инфаструктуры; Процесс усовершенствования; Процесс обучения.
2. Основные характеристики программного модуля по Г. Майерсу: размер, прочность, сцепление, рутинность
Не всякий прогр модуль способствует упрощению проги. Исп следующие два критерия для хорошего модуля: хороший модуль д/б снаружи проще, чем внутри и хороший модуль проще использовать, чем построить.
Использование на практике столь общих критериев представляется достаточно проблематичным. Поэтому Г. Майерсом для оценки приемлемости прогр модуля было предложено использовать след его конструктивные характеристики: размер; прочность; сцепление с другими модулями; рутинность (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций при отладке программы.
Прочность модуля это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Г. Майерс предложил упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль, прочный по совпадению (не рекомендуется для использования). Только два высших по прочности класса модулей рекомендуются для использования. Функционально прочный модуль это модуль, выполняющий (реализующий) одну какую-либо определенную функцию. Информационно прочный модуль это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля (это класс программных модулей с высшей степенью прочности).
Сцепление модуля это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Г. Майерс предложил упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Не рекомендуется использовать также сцепление по общей области это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Единственным видом сцепления модулей, который рекомендуется для использования, является параметрическое сцепление это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции.
Рутинность модуля это его независимость от предыстории обращений к нему. Модуль называется рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль называется зависящим от предыстории, если результат обращения к нему зависит от внутреннего состояния этого модуля, изменяющегося в результате предыдущих обращений к нему. Г. Майерс не рекомендовал использовать зависящие от предыстории модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация не всегда является конструктивной. Поэтому представляется более приемлемой следующая рекомендация: всегда следует использовать рутинные модули, если в не рутинных нет особой необходимости; зависящие от предыстории модули следует применять только в случае очень значительных выгод от их использования; в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение данного модуля при разных последующих обращениях к нему.
3. Общие принципы моделирования жизненного цикла программных средств…
Общие принципы моделирования ЖЦ ПС. Модель ЖЦ ПС – совокупность определенным образом взаимосвязанных процессов послед-ого изменения его сост-я, начиная от возникновения потребности в этом средстве, через формир-ние исходных требований к нему, его проектирование и т.д., заканчивая изъятием его из экспл-ции и послед-ей утилизацией. В ГОСТ Р ИСО/МЭК 12207 подробно описаны только структура и содержание процессов ЖЦ ПС, но не сказано о том, как эти пр-сы взаимноувязывать м/ду собой во времени и простр-ве в ходе конкр проекта, т.е. не приведены модели ЖЦ ПС. На настоящий момент никаких международных ст-тов или соглашений на использование м-лей ЖЦ ПС не сущ-т Осн фазами (этапами) разр-ки ПС будут след-щие: 1.анализ требований и составление спецификаций (ТЗ); 2. Проектирование (2.1.предварительное, 2.2.детальное); 3. программирование; 4. интеграция (сборка системы) и тестирование (4.1. тестир отдел-х модулей; 4.2. интеграция и тестир ПС; 4.3. системное тестир); 5. инсталляция и аттестационное тестирование.
 Модель «сделал-исправил». Это сам прост и распростр модель ЖЦ ПС. Иногда не считают за модель. Т.о., обычно, минуя фазы подробного анализа требований польз-ля, составления формальных и докум-ных спецификаций, а также проектирования, сразу приступают к прогр-ю и создают 1 версию ПС, кот затем модифицир, пока она не удовлетворит польз-ля. Эта схема хорошо раб-ет при изгот-нии оч маленьк и простых ПС (Лабы).
 Классическая каскадная или «водопадная» модель. создана по образу и подоб методик, наработанных в др инж-х областях, где сущ-т стандартная практика поэтапного создания продукта, начиная с составления ТЗ и зак поставкой заказчику. Модель реализует принцип однократного вып-ния кажд вида деят-сти в виде заранее ограниченных и однозначно упорядоченных во времени стадий, этапов или фаз проекта, осущ-мых как бы в их естественных границах.
При такой модели ЖЦ ПС работы и задачи,например, процесса разр-ки вып-ся четко послед-но: каких-л перекрытий, параллелизма или возвратов назад не допуск-ся. Это оч жесткое огранич-е, кот делает такую м-ль практич нереализуемой, т.к. недопустимы никакие ошибки на уже законченных этапах. Нужноя идеальное кач-во спец-ций, разраб-мых на самом первом этапе при явном дефиците информации, что также практически невозможно осуществить.
|
Дополнение к 15 Мини-спецификация и словари данных 42
