Внешнее проектирование программного изделия
29.10.10
Четвертый уровень (предсказуемый) – реализуются крупномасштабные проекты особо сложных программных средств с жестким ограничением по временным срокам и с высокими гарантиями. На этом уровне должны применяться система детального поэтапного оценивания характеристик качества как технологических процессов жизненного цикла, так и самого создаваемого программного продукта и его компонентов. Должны разрабатываться и применяться универсальные методики количественные оценки реализации процессов и их качества. На этом уровне надо совершенствовать управление проектами и благодаря этому можно скорректировать процесс в целом. Результаты процесса становятся предсказуемы по срокам и качеству.
Пятый уровень (оптимизируемый)– одна из основных целей этого уровня сокращение проявления потерь от случайных дефектов и ошибок путем выявления сильных и слабых сторон используемых процессов. Приоритетным является анализ рисков дефектов и отклонений от заданных требований заказчика. Эти данные используются для снижения себестоимости жизненного цикла в особо сложных программных средств в результате внедрения новых технологий инструментария, а так же для планирования и осуществления модернизации всех видов процессов.
Группа стандартов, которые целесообразно применять для обеспечения функциональной безопасности и высокого качества сложных программных средств. ИСО 127-82: 1998 «Информационная технология, классификация программных средств».
ИСО 91-26:1999 «Информационная технология. Оценка программного продукта. Характеристика качества и руководство по их применению».
ИСО 145-98:1998 «Оценивание программного продукта».
ИСО 147-56:1999 «Информационная технология. Измерение оценивание производительности программных средств компьютерных вычислительных систем».
ИСО 121-19:1994 «Информационные технологии. Требования к качеству и тестированию».
ИСО 158-46: 19998 «Процесс жизненного цикла программных средств, конфигурационные управления программными средствами».
ИСО 146-54:1999 «Информационная технология. Сопровождение программных средств».
ИСО 159-10:1999 «Информационная технология. Пользовательская документация программных средств».
Нижнее проектирование включает в себя 3 процесса:
1. Анализ и разработка требований.
2. Определение целей создания программного изделия.
3. Разработка внешних спецификаций проекта.
Для более качественного выполнения работа на начальной стадии проектирования целесообразно привлекать к формулировке требований потенциальных пользователей с учетом специфики проекта.
Требования к программному изделию должны разрабатываться небольшой группой лиц. Многие проблемы разработки программного изделия возникают в результате того, что требования были не поняты или плохо заданы. Требования должны включать ограничения на цели, среду пользователя, наполнение требуемых функций. Требования должны определять конечный продукт, но не подход к проектированию. В процессе разработки требований необходимо:
1) Выявить наличие информации, необходимой для выполнения планируемых функций.
2) Определить трудоемкость и стоимость предстоящей работы.
3) Обеспечить полноту и точность определения функций подлежащих выполнению программным изделием их взаимосвязь.
4) Выявить ограничения, налагаемые на систему, а так же средство системы, которые в будущем могут претерпеть изменения.
Анализ требований способствует лучшему пониманию решаемой проблемы и компромиссных ситуаций, что помогает выбрать оптимальное решение. Требования разрабатываются в 2 этапа:
1) На этом этап определяется реализуемость, устанавливаются цели, оцениваются затраты. В результате получается
2) Разрабатываются требования пользователя, т.е. вырабатываются требования к входным данным, информационным потокам, выходным данным, документации, среде, вычислительным ресурсам. Получаемая на этом этапе информация ориентирована на установление критериев для выходных результатов и задает функциональные возможности программного изделия. В результате должен быть сформирован документа, удовлетворяющий следующим требованиям:
1. Документ должен быть достаточен для …. Его среды, преимущества и недостатков программного изделия для пользователя, состава и конфигурации ресурсов его работы.
2. …
3. ….
Ответственным за полноту и точность к полноте формулирования требований к программному средству является пользователь. Проектировщик отвечает за качество описания требования и их реализуемость.
При описании цели возможно возникновение следующих ошибок:
· Противоречивость
· Наличие поверхностно выявленных целей, не отражающих специфических особенностей разрабатываемого ПО.
· Цели создания программного изделия с точки зрения пользователя и проектировщика могут быть противоречивы.
Цели проекта – это цели, которые должны быть достигнуты в процессе проектирования.
Цели проекта должны содержать следующую информацию:
· Стоимостные ограничения;
· Календарный план выполнения работ;
· задача каждого этапа тестирования;
· цели в области адаптируемости;
· уровень надежности на каждом этапе разработки.
· Критерии завершения разработки и начала адаптации.
Цели проекта должны быть ясными, обоснованными и измеримыми. Цель должны быть подробна, но не должна предполагать конкретных методов решения.
Внешние проектирование - процесс описания программных изделий с точки зрения потенциальных пользователей. Целью этого процесса является конкретизация внешних взаимодействий будущего программного изделия без детализации внутреннего устройства. Внешний проект предполагает собой описание внешних спецификаций программного изделия, которые предназначены для различных групп специалистов. При работе внешних спецификаций необходимо стремиться к концептуальной целостности проекта.
Разработка внешних спецификаций разбивается на 2 части: предварительный внешний проект и детальный.
Белый ящик – разработчик имеет доступ к исходному коду и может писать код, которые связан с библиотеками тестируемого ПО. Стратегия тестирования по принципу белого ящика, так же называемая стратегиями тестирования управляемая логикой программы позволяет проверить внутреннюю структуру программы. Стратегия БЯ включает в себя следующие методы тестирование:
1. Покрытие операторов.
2. Покрытие решений.
3. Покрытие условий.
4. Покрытие решений и условий.
5. Комбин арное покрытие условий.
Критерии покрытия операторов подразумевают выполнении каждого оператора программы хотя бы один раз. Это необходимое, но недостаточное условие для приемлемого тестирования. Этот критерий является весьма слабым, допускает много ошибок, т.к. выполнение каждого оператора программы хотя бы один раз есть необходимое, но недостаточное условие для приемлемого тестирования по методу БЯ.