Примеры итеративных процессов разработки

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

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

Пример: RationalUnifiedProcess (RUP) — методология разработки программного обеспечения, созданная компанией RationalSoftware.

Легковесные процессы (agile процессы) – делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы. Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки, появившемся в 2000 году. Основные принципы:

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

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

3. Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта;

4. Отработка изменений более важна, чем следование планам.

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

Пример: Экстремальное программирование.

Документация на сложные кп

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

В процессе разработки, отладки и эксплуатации документация выполняет следующие функции:

1. Формализует методы решения поставленных задач;

2. Формализует используемую информацию каждым компонентом системы и КП в целом;

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

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

5. Обеспечивает возможность контроля на этапахразработкикак со стороны заказчика, так и исполнителя;

6. Обеспечивает возможность замены разработчиком части персонала без полного повторения выполненной работы;

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

8. Обеспечивает возможность модификации и модернизации системы;

9. Позволяет использовать разработанные ранее компоненты, алгоритмы и прочее в различных частях одной системы или даже в разных системах (при профессиональной разработке в системе, как правило, не бывает больше 20% нового кода).

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

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

К международным стандартам в первую очередь надо отнести ISO (InternationalStandardOrganization). Эти стандарты касаются качества разработки ПС.

Отечественные стандарты условно подразделяются на 3 категории:

1. ГОСТ (Государственный Стандарт). Они должны выполняться на законодательном уровне;

2. ОСТ (Отраслевые Стандарты) – отражают специфику конкретной области (например, специфику разработок в оборонной промышленности). Разработчик несет ответственность за выполнение этого стандарта, а в крупных компаниях этим занимаются целые отделения;

3. СП (Стандарты Предприятий или стандарты группы разработчиков) - крайне желательно при выполнении лабораторных работ отработать СП.

Как ОСТ так и СП могут лишь расширять ГОСТы и не в коем случае им не противоречить.

ГОСТ 19 – единая система программной документации.

ГОСТ 34 – проектирование АСУ: документация, ПО, аппаратная часть.

Определение:ЕСПД (единая система программной документации) - это комплекс государственных стандартов, устанавливающих взаимосвязанные правила разработки, оформление и обращение программ и программной документации.

Правила и положения ЕСПД распространяются на программы и программную документацию для ВМ, комплексов и систем, независимо от их назначения и области применения.

ГОСТ 19.001 – 77

19 – класс стандарта (ЕСПД);

0 – классификационная группа (

0 – общие положения;

1 – основополагающие стандарты,

2 – правила выполнения документации разработки;

3 – правила выполнения документации исполнения;

4 – правила выполнения документации сопровождения;

5 – правила выполнения эксплуатационной документации;

6 – правила обращения программной документации;

7, 8 – резервные группы;

9 – прочие стандарты.)

01 – номер стандарта в группе;

77 – год первого принятия.

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