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

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

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

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

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

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

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

Разработка ПО – это одна из самых распространенных IT услуг. В серии этих постов постараюсь раскрыть суть данного вопроса 
Разработка ПО — это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.
Для любого бизнеса нужно иметь свое программное обеспечение. Это аксиома. Конечно проще купить готовое (в некоторых случаях), но иногда все же нужно подумать об уникальном решении.
Что же лучше? Ответ как по мне прост. Если вы готовы пожертвовать необходимым вам функционалом в угоду снижения стоимости ПО то тогда, конечно же, нужно купить уже готовое решение и подстроить свой бизнес под него. В противном случае – нужно разрабатывать ПО.
Основные преимущества Разработка ПО под заказ:
Наиболее важным преимуществом, разработанных программ, является простота их внедрения на любом предприятии в независимости от количества работников, отделов, наличия представительств и филиалов. Также, среди преимуществ можно выделить простоту их настройки и использования. С каждым клиентом работа на индивидуальной основе, учитывают все требования и пожелания, при необходимости разрабатывают комплекс рекомендаций и решений, необходимых для рационального функционирования программ.
Индивидуальный подход позволяет создавать программы исключительно для клиентов. А это означает, что будет учтена специфика бизнес-процессов, которые происходят на предприятии. Например, не будет никаких лишних или не нужных опций и функций, которые часто замедляют работу, запутывают обычного пользователя, что характерно для коробочного программного обеспечения, в то же время при разработке программ под заказ, в первую очередь необходимые опции максимально доступны и эффективны при использовании.

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

Внедрение системы отслеживания проблем
Для чего необходимо использовать систему отслеживания проблем?
На эффективность процесса тестирования и устранения дефектов оказывает большое влияние степень четкости процесса подготовки и анализа отчета о проблемах, а также наличие хорошего инструмента для его поддержки.
При отсутствии промышленного инструмента, группа тестирования может создать свою систему отслеживания проблем.
Цели системы отслеживания проблем:
• отслеживание состояния тестирования и устранения дефектов;
• организация взаимодействия между сотрудниками и решение спорных вопросов относительно классификации и приоритетов устранения дефектов;
• определение причин дефектов и выявление «узких» мест в процессах разработки и тестирования.
Три условия успешного старта
Таким образом, для первичной организации тестирования необходимо, образно выражаясь, выполнить условия трех «Ф», которые заключаются в следующем:
• формализации обязанностей – написании должностных инструкций и положения про отдел;
• формализации общения с программистами – внедрении BTS;
• формализации работы тестеров – создании контрольных примеров, планировании и получении отчета о тестировании.
Собственно, хороший производственный процесс тем отличается от плохого, что он не пущен на самотек, а упорядочен и управляем.

Введение в Software Testing

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

Терминология тестирования

Терминология тестирования
План Тестирования (Test Plan)
- это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design)
- это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Тестовый случай (Test Case)
- это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Баг/Дефект Репорт (Bug Report)
- это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage)
- это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Детализация Тест Кейсов (Test Case Detalization)
- это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию
Время Прохождения Тест Кейса (Test Case Pass Time)
- это время от начала прохождения шагов тест кейса до получения результата теста.