Принципы разработки больших кп

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

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

Каждый долгосрочный план проектирования должен содержать:

1. Формулирование общих целей разработки КП и частных целей разработки его подсистем;

2. Стратегию проектирования(в частности эксперименты по отладке);

3. Потребности в ресурсах различных видов;

4. Создание структуры коллектива разработчиков;

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

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

3. Необходимо намечать достижимые пределы по количественным и качественным параметрам КП, а также возможные сроки их достижения.

4. Стратегия проектирования должна обеспечивать выполнение поставленных задач с минимальными затратами. При этом она определяет:

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

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

Случай 1:

1. 5% - функциональная проработка (исследование предметной области);

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

3. 50% отладка.

Случай 2:

1. 35% функциональная проработка (исследование предметной области);

2. 10% кодирование или написание текста программы;

3. 35% отладка.

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

В реальных ситуациях второй подход выигрывает очень существенно.

Принципы организации коллективов разработчиков кп

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

2. Условная оценка производительности труда:

1. 1970 – 0.1 оператор/человек в день;

2. 1980 – 1;

3. 1990 – 5;

4. Настоящее время – 10.

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

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

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

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

7. Принято рассматривать 2 основных варианта построение бригады: «хирургическая бригада» и «производственная бригада»:

8. Организация «хирургической бригады» строится по следующему принципу:

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

2. Заместитель руководителя – решает те же задачи что и руководитель, действуя под его руководством и готовый в любое время его заменить. Основная задача – обсуждение, критика, советы, возможная связь с другими бригадами. Личной ответственности, при наличии руководителя, ни за какую часть программы не несет, но готов. Имеет возможность и квалификацию, чтобы в любой момент времени заместить главного программиста;

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

4. Редактор – его задачами являются критика документации руководителя а также непосредственная работа над документацией, возможно с какими-либо помощниками;

5. Инструментальщик – опытный системный программист, который разрабатывает и поддерживает системные и инструментальные ПС (тесты, библиотеки, инструментальные средства разработки и т.п.);

6. Наладчик – человек, готовящий тесты, имитаторы, генераторы тестов, определяет ход тестирования, регистрирует процесс отладки (возможно с помощником.);

7. Дополнительно имеется 2-3 технических работника: секретарь, библиотекарь, уборщица;

8. При этом программу, по сути дела, создает очень ограниченное количество людей вплоть до 2-3 человек;

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

9. Структуру «производственной бригады» можно представить следующим образом:

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

2. Заместитель руководителя - решает те же задачи, что и руководитель, но при этом несет меньшую личную ответственность. В любое время может заменить руководителя.

3. «Главный инженер» - опытныйдействующий программист и организатор. Задачи – создание структуры всего проекта, организация разработки, возможно решение кадровых вопросов.

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

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

6. Группа программистов – инструментальщиков. Задачи этой группы совпадают с инструментальщиками хирургической бригады. Часто эта группа состоит из 1 человека.

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

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

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

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