jonka Jorjio Jol'vani 8 kuukautta sitten
61
Lisää tämän kaltaisia
Степень знакомства программистов с языком программирования.
Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи избираемому языку программирования.
Избранная методология. Часто говорят, что язык поддерживает ту или иную методологию. Обычно это означает, что применение этого языка совместно с указанной методологией в совокупности дадут значительно больший эффект.
Сравнительная пригодность языка программирования для данной задачи.
Проверяйте коды возврата функций.
Проверяйте длину элементов информации.
Включайте автоматические проверки (например, контроль переполнения или потери точности).
Контролируйте итоги вычислений.
Выполняйте контроль правдоподобности значений переменных, которые не должны превышать некоторых констант или значений других переменных.
Делайте проверку области значений переменных.
Изолирование ошибки. Ошибки в одном модуле должны быть изолированы так, чтобы не допустить их влияние на другие модули.
Немедленное обнаружение. Каждая ошибка должна быть выявлена как можно раньше, это упрощает установление ее причины.
Общее недоверие. Для каждого модуля входные данные должны тщательно анализироваться в предположении, что они могут быть ошибочными.
Рекомендации по написанию определения функций.
Если часть then или else состоит из простого оператора, то открывающая и закрывающая фигурные скобки могут быть опущены.
Если условие не помещается на одной строке, то его продолжение на следующей строке должно начинаться в том же столбце, что и первый символ выражения первой строки.
Закрывающая фигурная скобка находится на том же уровне отступа, что и начало условного оператора.
Открывающая фигурная скобка должна находиться на той же строке, что и закрывающая круглая.
По одному пробелу следует оставлять перед и после круглых скобок условия.
Различные части функции следует отделять пустой строкой. Рекомендации по написанию условного оператора.
Определение функции всегда начинается в самом левом столбце файла.
Если функция статическая, то ключевое слово static должно быть вынесено в строку, предшествующую заголовку функции.
Заголовок состоит из типа возвращаемого функцией значения, пробела, имени функции, за которым без пробела следует открывающая круглая скобка для списка параметров.
Открывающая и закрывающая фигурные скобки, определяющие тело функции, располагаются в первом столбце строк.
Определение должно начинаться заголовком функции, за которым идут комментарий, описывающий назначение функции, и собственно тело функции.
Рекомендации по объявлению переменных.
Если переменная является указателем, то символ * следует присоединять к типу.
За типом переменной должны следовать пробел, имя переменной и комментарий с кратким описанием переменной.
Объявление переменной должно занимать одну строку.
В каждом объявлении должна объявляться только одна переменная.
Рекомендации по написанию выражений.
Если выражение переносится на следующую строку, то знак бинарной операции следует оставить на первой строке.
Старайтесь размещать выражение на одной строке.
Используйте скобки, чтобы улучшить читаемость. Не следует добавлять пробелы к введенным скобкам.
Унарные операторы не следует отделять от операнда пробелом, если только этого не требуют правила языка.
Бинарные операторы должны быть отделены от операндов одним пробелом.
Рекомендации по выравниванию.
Табуляционный отступ равен восьми пробелам.
Стандартная величина отступа равна четырем пробелам.
Рекомендации по написанию идентификаторов.
Строковые комментарии следует использовать для коротких заметок в одну-две строки.
Блочные комментарии следует применять для описания дополнительной информации о файле, классе, функции или переменной.
Имена перечислимых типов могут иметь единый префикс. Приведем рекомендации по употреблению комментариев.
Имена функций должны быть активными, т. е. базироваться на активном глаголе, за которым следует существительное.
Длинные имена могут быть сокращены. Следует придерживаться либо удаления несущественных суффиксов, либо удаления всех гласных букв кроме начальной, либо использования нескольких первых букв слова.
Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, р и q для указателей, s для строковых, a ch для литерных переменных. В данном случае ясность достигается краткостью.
Смысл всех имен должен быть понятен при чтении программы.
Идентификаторы должны начинаться со строчной буквы. Опишем соглашения об именовании.
Разделяйте части идентификаторов символом подчеркивания, а не написанием с большой буквы очередной части идентификатора.
Не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв - строчной или прописной.
Не используйте идентификаторы, состоящие только из прописных букв. Исключения составляют имена констант и макроопределений.
Не начинайте и не заканчивайте идентификаторы символом подчеркивания.
Рекомендации по организации файлов
Для файлов кода на языке C++ рекомендуется такая последовательность
импортируемые интерфейсы;
комментарий к файлу;
Следует соблюдать следующий порядок в заголовочных файлах программы на языке C++:
Рекомендации по длине строк.
Лучше всего, если длина строк программы значительно короче 80 символов.
Строки не должны быть длиннее 80 символов.
Рекомендации по именованию файлов.
Все файлы должны иметь различные имена, даже если они находятся в разных каталогах.
Имена файлов должны отличаться уже первыми восемью символами.
Заголовочные файлы должны иметь расширение h. Файлы с программой на языке С должны иметь расширение с, а с программой на языке C++ - ее или cpp
16 основных практик
Ответственность и подотчетность руководства перед сотрудниками. Такая мотивация сотрудников может значительно повысить производительность труда программистов.
Конфигурационное управление. Использование систем управления исходными кодами, позволяющих отслеживать изменения и дающих возможность вернуться к предыдущим версиям.
Отслеживание причин возникновения ошибок для достижения высокого качества. Ошибки должны быть формально отслеживаемы, каждый случай обнаружения и устранения ошибки должен быть обязательно документирован.
Свободный доступ к информации о ходе проекта. Проект будет испытывать большие трудности, если менеджер скрывает от остальной команды информацию о состоянии проекта.
Контроль качества на детальном уровне. Промежуточные итоги должны подводиться еженедельно или даже ежедневно.
Планирование и управление на основе метрик. В основу планов и оценок должны быть положены числовые оценки - метрики, накопленные в предыдущих проектах.
Формальные проверки проекта. Экспертизы, проверки, сквозной контроль - все те действия, которые позволяют устранить ошибки как можно раньше.
Согласованность интерфейсов. Интерфейсы - необходимая часть архитектуры. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется проектировать заново.
Формальное управление рисками. Рекомендуется постоянно вести и анализировать списки основных важнейших рисков. У сотрудников не должно быть никаких иллюзий о допустимости рисков.
Дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.
Дать возможность руководителям проектов применять лучшие мировые практические навыки с учетом локальной корпоративной культуры.
Дать возможность руководителям проектов сфокусировать свои усилия на разработке качественного программного обеспечения, нежели на следовании должностным инструкциям и формальным методикам, которые только ухудшали состояние проекта.
Внедрить лучшие практические навыки создания программного обеспечения.
Не перегружать исполнителей задачами, для исполнения которых потребуется больше времени, чем есть в реальности.
Определить последовательность работ для каждого исполнителя.
Назначать опытных и квалифицированных людей на наиболее сложные задачи в критическом пути. Людей с меньшим количеством опыта - на менее сложные задачи и т. д.
Методика приближенных вычислений. Существует несколько расчетных формул для времен выполнения задач проекта. Введем три оценочных времени - оптимистичное (О), реальное (Р) и пессимистичное (П). Тогда время выполнения задач проекта можно вычислить по:
формуле Симпсона: О+4*Р+П/б.
формуле трапеций: O+2*Р+П/4
Методика исторических соотношений. Стоимость одного проекта относится к стоимости другого пропорционально отношению их объемов в некоторой степени п. Степень n - число, которое надо знать или подобрать опытным путем.
Методика норм работы. Учет ведется по нормам, определяемым как среднее значение времени, уходящее на данную работу в данной компании. Например, время, уходящее на разработку одной строки машинного кода.
Снизу вверх по составленному графику работ. Данные по трудозатратам и времени берем от исполнителей.
верху вниз по крупным блокам аналогичного проекта. Поскольку аналогичный проект пройден и мы знаем реальные затраты для него, то для нового проекта берем соответствующие цифры с некоторыми поправками.
Создание инфраструктуры управления.
Выявление критических путей.
Оценка рисков, связанных с конкретными задачами.
Определение времени выполнения задачи.
Проведение персональных назначений на задачи.
Определение зависимостей между задачами.
Распределение ответственности.
Выделение требуемых ресурсов.
Оценка затрат.
Составление графиков выполнения работ.
Построение списка задач.
координировать и контролировать выполнение работ для соблюдения календарного графика и завершения проекта в срок.
планировать завершение работ в нужные сроки в соответствии с требуемой последовательностью выполнения заданий;
заблаговременно планировать работу над проектом и предвидеть возможные источники затруднений и задержки выполнения его в срок;
Духовность и психическое здоровье в основе деловой и поведенческой практики.
Профессионализм и мастерство. Коллективизм, поддержка и взаимопомощь.
Справедливость, основанная на понимании и принятии правовых норм.
Согласие и сотрудничество в обществе.
Честь и достоинство личности.
Социальные права личности.
Партнерство и сотрудничество в производственных отношениях.
Группа важнее отдельной личности. Этот принцип основан на традиционной японской ценности - никто не должен быть эгоистичным и думать только о себе.
Рабочие образуют "семью". Методы реализации принципа:
взаимные обязательства фирмы и рабочих. Если сотрудник фирмы вступает в брак или у него рождается ребенок, то он получает денежную прибавку, поскольку его расходы возросли.
свободное время работники фирмы проводят вместе;
работники фирмы оказывают новичку помощь, сочувствие и поддержку, ожидая от него в дальнейшем проявления такого же поведения по отношению к ним;
Рабочий стремится сделать свою работу лучше. Методы реализации этого принципа:
премирование рабочих в случае повышения прибыли фирмы. Заметим, что в неблагоприятной ситуации руководящий состав получает значительно более урезанную зарплату, чем рабочие.
пожизненный найм работников;
Рабочий достаточно разумен, он самостоятельно увеличивает производительность и качество своего труда. Три административных метода помогают претворить этот принцип в жизнь:
практика перевода рабочих с одного места на другое. Работник повышает квалификацию, меняет специализацию и продвигается по служебной лестнице.
практика стимулирования всех работников к совершенствованию профессиональных умений и навыков. Здесь очень интересно то, что японская традиция "минарай" - наблюдение за опытными рабочими с целью освоения их навыков - очень близка русской традиции наставничества;
кружки качества;
Контролируй исполнение.
Разделяй обязанности среди подчиненных.
Анализируй состояние инженеров, запросы рынка, процесс создания программного продукта.
Особенности американского менеджмента
Подчиненность личных интересов общим. Интересы отдельного работника или группы не должны превалировать над интересами компании.
Корпоративный дух, т. е. гармония персонала, его сплочение.
Справедливость: сочетание доброты и правосудия.
Вознаграждение персонала, в том числе справедливая зарплата.
Дисциплина, т. е. послушание и уважение к достигнутым соглашениям между фирмой и ее работниками. Дисциплина предполагает также справедливо применяемые санкции.
Уникальность и важность. Уникальность должна объяснять - почему надо создавать данный программный продукт, почему нельзя взять что-то готовое. Элемент важности должен демонстрировать - почему разрабатываемый продукт нужен и важен заказчику, какие нужды и потребности заказчика он покрывает.
Ограниченная протяженность во времени с определенным началом и концом. Проект имеет определенный срок. Иногда этот срок плавающий, например, начинающийся от некоторой еще не определенной даты вступления договора в силу. Проект существует столько времени, сколько его требуется для получения конечного результата.
Координированное выполнение взаимосвязанных действий. Здесь следует еще раз вспомнить сложность разработки программного продукта. Взаимосвязи в проекте не всегда очевидны. Некоторые задания должны выполняться строго последовательно, а некоторые - строго параллельно.
Направленность на достижение конкретных целей. Действительно проекты направлены на получение определенных результатов. Кстати, цели должны быть сформулированы так, чтобы всегда было ясно, что цель достигнута и проект можно заканчивать. Проект обычно предполагает наличие промежуточных целей, которые вместе образуют взаимосвязанный комплекс.
Технический руководитель (лидер) проекта - инженер-технолог, обладающий техническими знаниями и опытом.
Управляющий (менеджер) проекта - руководитель, обладающий организационными знаниями и опытом.
Обязанности управляющего
Исключительная ответственность менеджера заключается:
в ответственности за поступление средств.
в том, чтобы проект отвечал требованиям заказчика. Руководитель должен держать заказчика в курсе всех событий проекта;
в руководстве проектом и контролем его выполнения. Менеджер отвечает за ежедневное руководство данным проектом. Хороший менеджер отводит различные проблемы от группы, он "гасит" нагоняи от заказчика или вышестоящего руководства;
в управлении сотрудниками. Менеджер ищет и привлекает лучших специалистов и экспертов для решения возникающих проблем;
в организации взаимосвязей внутри организации;
Совместная деятельность менеджера и лидера проекта включает:
выбор наилучшей стратегии.
распределение работ;
планирование проекта;
Инженеры (внеменеджментовые служащие). Именно инженеры заняты разработкой и созданием программного продукта.
Управляющие первичного звена (менеджеры проектов, менеджеры-координаторы). Одна из важнейших задач этой категории управляющих - планирование на уровне программных проектов. Далее мы сконцентрируемся на изучении обязанностей только менеджеров проекта.
Управляющие среднего уровня (менеджеры структурных подразделений). В их задачу входит координация и стратегическое планирование деятельности структурного подразделения.
Высший менеджмент (президент фирмы, председатель совета директоров, исполнительный президент, вице-президенты). В его задачу входит определение генеральной линии компании.
Стратегию человеческих отношений.
Маркетинговую стратегию.
Финансовую стратегию.
Оперативную стратегию.
Стратегию в области исследования и развития.
Тесное взаимодействие с группами поддержки и продаж.
Обеспечение эффективного взаимодействия между командами разработчиков, быстрое создание и вхождение в процесс разработки таких команд.
Соблюдение многочисленных стандартов.
Принятие ясных и документированных решений.
Наилучшая расстановка приоритетов и ресурсов.
Наличие формализованной модели для разработки программного продукта.
Стоимость сопровождения.
Класс решаемой задачи.
Ручное тестирование, которое проводится без исполнения тестируемой программы на компьютере.
Стохастическое тестирование, при котором исходные тестовые данные берутся случайным образом, как правило, с использованием статистического распределения.
Детерминированное тестирование, при котором контролируется каждая комбинация исходных эталонных данных и соответствующая ей комбинация результатов функционирования программ. На практике полное детерминированное тестирование обычно нереализуемо.
Тестирование программы как прозрачного (белого) ящика подразумевает знание исходного кода программы и полный доступ к нему.
Тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.
Подход Ивара Якобсона (Object-Oriented Software Engineering - OOSE).
Подход Джеймса Рамбо (Object Modelling Technique - ОМТ).
Подход Град и Буча.
Подход Шлеер-Меллора.
диаграммы последовательности.
диаграммы деятельности;
Моделирование процессов - для определения функций, которые система должна выполнить. Используются:
Моделирование состояний - для определения, зависящего от времени поведения системы. Используются диаграммы состояний.
Информационное моделирование - для определения отношений между данными (информацией). При этом используется один тип диаграмм: Диаграммы классов.
Подход на основе языка UML.
Информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с неиерархическими структурами данных.
Подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны.
Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.
Диаграммы последовательности.
Сверху вниз, в виде вертикальных линий, представляющих линию жизни отдельного объекта. Линия жизни - время, в течение которого объект существует в системе.
Слева направо, в виде линий жизни каждого объекта, участвующего во взаимодействии. Есть начальный момент времени - верхняя часть диаграммы, где указываются имена объектов.
Процессы проверки, которые проверяют условие и исполняют один из нескольких условных выводов управления.
Процессы преобразования, основной целью которых является вычисление или преобразование данных.
Генераторы событий, создающие событие, как результат работы.
Процессы доступа, единственная цель которых заключается в получении доступа к элементам одного архива данных объекта.
Диаграммы состояний.
и, наконец, исчезают или умирают.
затем эволюционируют, проходя через определенные стадии существования;
сначала они появляются или создаются;
Диаграммы классов.
Диаграммы вариантов использования.
интерфейс - спецификация параметров системы, которые видимы извне без указания их внутренней структуры.
актер (actor) - любая внешняя по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функции и возможности;
вариант использования (use case) - типичное взаимодействие пользователя и системы. Оно охватывает некоторую очевидную для пользователя функцию, решая некоторую дискретную задачу;
КОК-карты (класс-ответственность-кооперация).
Диаграммы функционального моделирования.
дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между ними. Место соединения дуги с блоком определяет тип интерфейса:
механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
результаты (выходная информация) показаны с правой стороны;
входная информация, подвергающаяся обработке, показана с левой стороны блока;
управляющая информация входит в блок сверху;
блоки, изображающие активность моделируемой системы;
Диаграммы декомпозиции.
Диаграммы зависимости.
Сети Петри.
Таблицы решений.
Диаграммы потоков управления.
Диаграммы потоков данных.
поток данных - механизм, определяющий информацию, передаваемую через некоторое соединение от источника к приемнику.
накопители данных - абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь;
процессы - совокупность операций по преобразованию входных данных в выходные в соответствии с определенным алгоритмом;
внешние сущности - материальный предмет или физическое лицо, представляющее собой источник или приемник информации;
Диаграммы развертывания.
Диаграммы компонентов.
Диаграммы кооперации.
Примеров, указывая экземпляры и связи, образующие отдельные роли в кооперации.
Спецификации, показывая роли классификаторов и ассоциаций в рассматриваемом взаимодействии.
Псевдокод.
Схемы экранов.
Блок-схемы.
Диаграммы переходов состояний.
Диаграммы Варнье-Орра.
Диаграммы деятельности.
Структурные карты.
Диаграммы "сущность-связь".
метод наведения мостов.
метод проектирования предметных областей;
метод расширения ядра.
метод восходящего проектирования;
метод нисходящего проектирования;
Анализа сообщений - при котором анализируются потоки данных, обрабатываемые модулями.
Пошагового уточнения - при котором на каждом следующем этапе декомпозиции определяются модули очередного, более низкого уровня.
Явления, ненаблюдаемые в обществе воспитанных людей
Явления, ненаблюдаемые в природе
Явления, ненаблюдаемые в принципе
Явления, ненаблюдаемые по определению
Взаимодействия - объекты, получающиеся из отношения между другими объектами.
Инциденты - абстракции чего-то произошедшего или случившегося.
Роли - абстракции цели или назначения человека, части оборудования или организации.
Реальные объекты - абстракции фактически существующих предметов в физическом мире.
Кроме этих четырех часто используются и другие структуры.
Структура классов.
Структура использования.
Структура потоков управления.
Структура потоков данных.
Структура вызовов.
Физическая структура, определяющая отображение элементов программного средства на аппаратное обеспечение.
Процессная структура, описывающая поведение системы во время ее исполнения.
Модульная структура, определяющая организацию программного средства как совокупности модулей - программных единиц, с которыми могут быть соотнесены рабочие задания, выполняемые членами проектной команды.
Логическая (концептуальная) структура, включающая множество абстракций, необходимых для описания функциональных требований к системе на абстрактном уровне (уровне, не затрагивающем вопросы реализации). Данная структура строится на основе анализа проблемной области.
коллектив параллельно выполняемых программ.
слоистая программная система;
комплекс автономно выполняемых программ;
цельная (монолитная) программа;
Представление с помощью информационных объектов. Как правило, таким способом представляются модельные спецификации.
Текстовое представление, которое подходит для словесных и формальных спецификаций.
Формальные спецификации, получаемые строгим формальным способом с использованием математических формализмов, которые обеспечивают полное определение семантики.
Модельные (структурированные) спецификации, которые предполагают построение схем, диаграмм, других информационных структур.
Словесные спецификации, обработка которых может осуществляться обычным текстовым редактором.
Ресурсы
Основные даты
Список основных документов
Зависимости
Описание технического процесса
Сравнительный анализ
Пользователи документа
Описание особенностей поставки
Введение
Краткий обзор
