Аутсорсинг. Часть 1

У нас в компании недавно спорили - что такое аутсорсинг. Это услуга. Или наша дополнительная заслуга. Просто форма взаимодействия с заказчиком. И вообще. Ну зачем, зачем, зачем это нужно на наших просторах.
И нужны ли мы с этим аутсорсингом на чужих ( при живых то индусах, китайцах…)

Для начала процитирую то, что пишется везде:
Аутсорсинг (от англ. outsourcing; outer-source-using) использование внешнего источника/ресурса) — передача организацией определённых бизнес-процессов или производственных функций на обслуживание другой компании, специализирующейся в соответствующей области. В отличие от услуг сервиса и поддержки, имеющих разовый, эпизодический характер и ограниченных началом и концом, на аутсорсинг передаются обычно функции по профессиональной поддержке бесперебойной работоспособности отдельных систем и инфраструктуры на основе длительного контракта (не менее 1 года). Наличие бизнес-процесса является отличительной чертой аутсорсинга от различных других форм оказания услуг и абонентского обслуживания.
О повышенном внимании к аутсорсингу как к бизнес-модели, способной снизить издержки и потому особенно востребованной в кризисные времена, говорит маркетинговая активность множества ИТ-компаний, отмечается в текущем году. Интересно оценить, в какой мере сбываются надежды на рост этого бизнеса, что тормозит и что стимулирует его, какие направления выглядят наиболее перспективными. При этом не стоит забывать, что ИТ-аутсорсингом занимаются фирмы разного профиля, в том числе телеком-провайдеры, дистрибьюторы —системные интеграторы. Для всех них это бизнес побочный, и лишь небольшое число «чистых» сервис-провайдеров заняты именно предоставлением IT услуг разного толка.

Разработка ПО. Часть 6

В процессе кодирования программеры чаще всего стараются добиться внутренней красоты разработанного ПО. Как бы странно это не показалось на первый взгляд, но именно внутренняя красота позволяет проекту впоследствии легко меняться и подстраиваться под изменяющиеся требования.
Работа с кодом - это искусство которому посвящены тома литературы. Вот основные моменты, сочетание которых позволяет создавать качественный, простой и надёжный код.
• Самотестирующийся код, т.е программа сама проверяет, что она правильно выполняет свои функции. Это очень мощная техника, которая позволяет устранить большинство ошибок и снизить расходы на тестировщиков.
• Рефакторинг, а на русском языке - это постоянное улучшение внутренней структуры кода. Это поддержание внутренней красоты. И хотя красота субъективна, поверьте, что все настоящие профессионалы знают о том, что такое некрасиво или дурной запах в коде.
• Работа в парах. Это не глупость и не причуда. Программисты действительно работают в парах более эффективно. Опыт подтверждает, что при парной работе создаётся намного более качественный продукт и чаще всего быстрее, чем это обычно делают два программиста по отдельности. Добавьте сюда ещё коллективное знание о деталях проекта.
После качественного кодирования продукт должен обязательно пройти через тестирование. QA лаборатория , или по-русски лаборатория контроля качества, имеет всё что нужно для того, чтобы удостовериться в соответствии полученного результата тем требованиям.
Огромную роль в тестировании, которое выполняют профессионалы, имеет автоматизация. Все тестировщики являются программистами в большей или меньшей степени, потому что им ежедневно приходится программировать.
И самый приятный этап, это внедрение и поддержка. Он наступает сразу после того, как происходит выпуск первой версии вашего продукта. Разрабатывают всю необходимую документацию, помогают определиться с выбором оборудования, установим и настроим всё, что нужно.

Разработка ПО. Часть 5

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

Часть 4 ПО и проблемы )

 Недостаточная надежность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали Кнут, Дейкстра и Вирт. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках. Особенно крупный вклад в дисциплину программирования внёс Дональд Кнут. Его четырёхтомник «Искусство программирования» является необходимой для каждого серьезного программиста книгой.
Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.
 Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.
Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).
Разработка ПО может кстати быть и не полная. Т.е. иногда можно что называется доработать ПО, если конечно же это ПО позволяет сделать такие фокусы. (обычно оно должно быть написано с помощью открытых стандартов)
Если у вас есть своя служба ИТ департамента то можно разработавать ПО и своими силами. Кстати, в этом случае некую часть разработки можно отдать на сторону. Например, стадию бизнес-анализа или тестирования. В этом случае вы будете уверены в качестве создаваемого ПО. Ведь не секрет, что программисты любят замалчивать о своих ошибках или приуменьшать их важность.

Часть 3 ПО и проблемы )

 Недостаток трассировки.
 Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки ПО в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени.
Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами, сравнима со стоимостью разработки самой программы.
 Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств.
Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.

Часть 2 ПО и проблемы )

В данной статье я постараюсь рассказать про наиболее распространёнными проблемами, возникающим в процессе разработки ПО .
Проблем, сами понимаете, много. Следовательно буду делить их на несколько частей. А также буду признательна за комментарии и дополнения по данному поводу.
 Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.
Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
 Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы.
Данная проблема возникает на этапе, когда проект, завершённый более, чем на половину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.