Автоматизированные средства разработки ПО

CASE – средства(Computer–aided Software engineering) – это специальный тип ПО предназначенный для поддержки процессов создания ПО. Примеры CASE-средств: текстовые редакторы, компиляторы, отладчики, генераторы отчетов и т.д. CASE- технологии предлагают поддержку создания ПО, путем автоматизации некоторых этапов разработки, а так же создания и предоставления информации необходимой для разработки. Примеры процессов которые можно автоматизировать:

1) Разработка графических моделей системы, на этапах создания спецификации и проектирования.

2) Генерация «скелета» программы на основе созданного ранее проекта. Генерирование UI на основе графического описания интерфейса создаваемого в диалоговом режиме.

3) Автоматическая трансляция исходного кода из одного языка в другой.

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

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

2) Создание ПО как правило является результатом работы команды специалистов. При этом много времени тратиться на общение между членами команды разработчиков. В этом случае CASE-технологии не могут ничего предложить.

Конвенции программирования.

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

Правило №1:

Организовывать доступ к глобальным переменным через методы.(set…() & get….());

Правило №2:

Классы и модули должны содержать максимум по 9 членов данных и методов.

Правило №3:

Избегайте создания «божественных» классов(модулей).

Правило №4:

Минимизируйте сотрудничество классов(модулей) с другими классами(модулями). Т.е. вызовы методов других классов и данных. Правило Деметра – в ООП. Класс А может вызывать любые свои методы и использовать свои данные, если в классе А создается объект Б, то А может использовать методы класса Б, но классу А не следует вызывать методы класса С возвращаемого объектом Б.

Правило №5:

Предвосхищайте изменения,.

Методы.

Метод – это отдельная функция или процедура, решающая одну конкретную задачу.

Цели создания: Сокрытие кода и минимизация кода.

Правило №1:

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

Правило №2:

Выделение фрагмента кода в удачно названный метод, позволяет задокументировать цель метода в его имени.

Правило №3:

Сокрытие очередности действий. Если вам нужно вызвать в несколько методов строгой последовательности записывайте их вызов в отдельный метод и уже вызывайте этот метод.

Правило №4:

Имена методов. Должны отражать суть метода. Длина имени метода в идеальном случае должна составлять от 9 до 16 знаков. Если имя получается очень длинным пересмотрите свой метод. Не используйте цифры в именах. При именовании функции старайтесь внести возвращаемые ею результат в имя.

Сигнатура методов. Ограничивайте число входных параметров от 5 до 9.

Именование входных параметров. Старайтесь чтобы фактические и формальные параметры совпадали.

1.Используйте все передаваемы параметры.

2. Не используйте входные параметры для хранения промежуточных значений.

3. Поразмыслите над использованием конвенций именования параметров.

I_ - input

M_ - modify

O_ - out

Возможно перед именами формальных параметров следует поставить префикс.

Объем методов. Не бойтесь использовать маленькие методы(5-10 строк). Рекомендуемый размер метода не более 200 строк.

Переменные и числа.

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

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

Перед глобальными переменными g_.

Перед именем типа t_.

Для обозначения констант c_ или имя конст записывайте заглавными буквами.

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

Управление проектом.

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

1) Программный продукт не материален.

2) Не существует стандартных процессов разработки ПО.

3) Большие программные проекты, как правило одноразовые.

Процессы управления.

В большинстве проектов менеджер ответственен за выполнение следующих процессов:

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

2) Планирование и составление графика работ по созданию ПО. Здесь определяются процессы, этапы и результаты их выполнения, которые должны привести к реализации проекта.

3) Определение стоимости проекта. Оценка стоимости напрямую зависит от этапа планирования, поскольку здесь оцениваются ресурсы требующиеся для выполнения плана.

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

5) Подбор персонала. Руководители проекта как правило подбирают персонал самостоятельно, в ряде случаев профессиональный уровень работников может не соответствовать той работе которая не будет выполняться. Это может быть вызвано следующими причинами:

1) Бюджет проекта не позволяет привлечь высококвалифицированных специалистов и за меньшую плату нанимаются менее квалифицированные.

2) Возможна ситуация когда не возможно найти специалиста нужной квалификации внутри и вне организации. Например когда специалист уже занят в другом проекте.

3) Повышение квалификации, т.е. менее квалифицированные сотрудники работают в тандеме с более квалифицированными, в процессе работы повышая свой опыт.

6) Написание отчета.

Планирование проектов.

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

Процесс планирования создания ПО.