Блог О пользователеwritergirl

Регистрация

Календарь

« Июнь 2011  
Пн Вт Ср Чт Пт Сб Вс
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
1 |2 |3 |4
 

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


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

Разработка информационных систем


Информационная система представляет собой совокупность инструментов, направленных на организацию различных рабочих процессов в любой сфере деятельности. Существуют информационно-справочные системы, поисковые, системы обработки данных, а также решающие системы. В разработке информационных систем могут нуждаться как крупные компании и предприятия, так и небольшие организации и частные лица. Разработка информационных систем проводится с учетом всех целей и задач, предъявляемых заказчиком, и состоит из нескольких этапов: анализ специфики компании; разработка проектной и технической документации, в которую будут включены все функции, архитектура системы, а также сроки и стоимость создания; создание прототипа и тестирование; внедрение системы; дальнейшая работа по поддержанию информационной системы.
 

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


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

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


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

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


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

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


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

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


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

Управления тестированием


Внедрение системы отслеживания проблем

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

Цели системы отслеживания проблем:

  • отслеживание состояния тестирования и устранения дефектов;
  • организация взаимодействия между сотрудниками и решение спорных вопросов относительно классификации и приоритетов устранения дефектов;
  • определение причин дефектов и выявление «узких» мест в процессах разработки и тестирования.

Три условия успешного старта

Таким образом, для первичной организации тестирования необходимо, образно выражаясь, выполнить условия трех «Ф», которые заключаются в следующем:

  • формализации обязанностей – написании должностных инструкций и положения про отдел;
  • формализации общения с программистами – внедрении BTS;
  • формализации работы тестеров – создании контрольных примеров, планировании и получении отчета о тестировании.

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


 
 
 

Введение в Software Testing


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

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

QA (от англ. Quality assurance — обеспечение качества) — это управление качеством процесса, который используется для создания качественного продукта. В отличии от тестирования, которое чаще всего является «контролем качества», обеспечение качества направлено на внесение изменений не только в процесс тестирования, но также во все другие этапы разработки, выпуска и эксплуатации ПО. Все это необходимо для достижения уверенности, что продукт удовлетворит все качественные потребности пользователя.

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


 
 
 

Мифы о профессии "Тестировщик ПО"


Тестирование видится с одной стороны каким-то полумеханическим процессом, который не требует особенной квалификации: тестировщика видят «кликальщиком», который просто гоняет приложение, ждёт пока оно «упадёт», потом сообщает об ошибке и продолжает в том же духе. В последнее время, надо отдать должное, появляются материалы о тестировании и качестве, выходят в свет книги, развиваются сайты посвящённые этому направлению — это направление профанирующее профессии постепенно сходит на «нет».
С другой точки зрения, которую, наверное, культивируют отчасти и сами тестировщики (в самом широком смысле этого слова), тестирование — это процесс, покрытый множеством неопределённостей, трудно формализируемый и поддающийся оценкам. Если же к тестированию добавить автоматизацию, которая по оценкам тех, кто внедрял инструменты и решения для тестирования, требует больших (по сравнению с ручным тестированием) трудозатрат и говорить об оценке качества продукта, направление тестирования получается совсем непрозрачным для стороннего наблюдателя, а порой и для самих тестировщиков.

 
 
1 |2 |3 |4