Отчёт Производственная практика ПМ02. Отчёт ПП ПМ02. Отчет по практике вид практики производственная практика (по профилю специальности) в составе
 Скачать 267.93 Kb.
|
 СПЕЦИАЛЬНОСТЬ: 09.02.07 Информационные системы и программирование ОТЧЕТ ПО ПРАКТИКЕ вид практики ПРОИЗВОДСТВЕННАЯ ПРАКТИКА (ПО ПРОФИЛЮ СПЕЦИАЛЬНОСТИ) В СОСТАВЕ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ ПМ.02 Ревьюиривование программных продуктов ПЕРИОД ПРОВЕДЕНИЯ: 3 семестр 2 курс ВЫПОЛНИЛ СТУДЕНТ (КА): Попов Александр Олегович фамилия, имя, отчество полностью КУРС: 2 ГРУППА: _КБсп 110/с1-20 __________ РУКОВОДИТЕЛЬ ПРАКТИКИ ОТ КОЛЛЕДЖА подпись ФИО ОЦЕНКА ДАТА МОСКВА 2021г. ВВЕДЕНИЕПроизводственная практика, является важной частью подготовки квалифицированных специалистов. Она помогает закрепить теоретические знания и даёт нам возможность воспользоваться ими в период прохождения практики. Производственная практика по ПМ 02. Обеспечение проектной деятельности проходила в ФССП с 29.11.2021 по 12.12.2021 на должности помощник Федеральной Службы Судебных Приставов Российской Федерации. Работа велась в здании данной организации по адресу: город Москва, улица Мишина д. 56 стр. 8, стр.9 Работа заключалась в осуществление интеграции программных модулей, а также выполнение заданий, выданных моим учебным учреждением для освоения и закрепления полученных мной знаний в течении учебного времени. АНАЛИЗ ВЫПОЛНЕНИЯ ЗАДАНИЙ ПО ПРАКТИКЕ ОТ КОЛЛЕДЖАЗадание 1. Разработка спецификации на программный продукт. Разработка функциональной диаграммы. Разработка диаграмм потоков данных. Разработка эксплуатационной документации на программный продукт. 1.1 Разработка спецификации на программный продукт.Спецификация программного продукта - это набор требований, описание программного продукта и его внешних интерфейсов. Они предназначены для того, чтобы разработчик и заказчик могли договориться о том, как должен выглядеть программный продукт и какие функции должны выполняться. Это делается для того, чтобы разработчик изначально знал требования к программному продукту, который он должен создать. В противном случае заказчик может потратить большую сумму денег на разработку этого программного продукта, который, возможно, не сможет выполнять желаемые функции после разработки. Для крупных компаний в большинстве случаев это может привести к большему количеству потерь любого положительного качества. Теперь мы рассмотрим рекомендованную методологию разработки спецификаций и их стандарты в соответствии с IEEE 830. Эта методология описывает рекомендуемые стандарты для создания спецификации требований к программному продукту. Во-первых, программный клиент должен точно и ясно описать, что он хочет получить от разработки. Во-вторых, разработчик, в свою очередь, должен точно понимать, чего хочет клиент. Если в этом контракте есть отдельные лица, они должны сделать следующее: 1. Разработайте схему спецификации программного продукта (SRS) для вашей организации; 2. Тщательно определите формат и содержание вашей спецификации требований к программному продукту. 3. Подготовить дополнительные подтверждающие документы, такие как: Контрольный список качества SRS или Руководство для составителя SRS; Хорошо подготовленная спецификация должна принести пользу как заказчику, так и разработчику, а также людям, а именно: создание основы для соглашения между заказчиком и разработчиком о том, какие функции должен выполнять программный продукт. Полное описание функций программного обеспечения, представленное в спецификации, поможет потенциальным пользователям определить, соответствует ли программное обеспечение их требованиям или как они могут изменить программное обеспечение в соответствии со своими требованиями: сокращение объема работ по разработке. Подготовка спецификации обязывает клиента строго учесть все свои пожелания перед тем, как разработчик приступит к работе. Это поможет избежать редизайна, кодирования и тестирования. Правильный анализ требований, указанных в спецификациях, может прояснить некоторые возможные упущения, такие как недопонимание требований, противоречия на этапе разработки, так как их будет намного легче исправить, когда вы уже начали разработку. Нужно оценить затраты и планы развития. Разработка программного продукта по уже заранее оформленной спецификации поможет оценить расходы на проект, а после, может использоваться для утверждения этого проекта на основании этих оценок. Критерии создания качественной спецификации SRS: Сущность SRS; Среда SRS; Характеристика качественной SRS; Совместная подготовка SRS; Развитие SRS; Макетирование; Внедрение структуры в SRS; Внедрение требований проекта в SRS; Сущность SRS SRS – как я уже писал выше, это спецификация для определенного программного изделия, продукта или набора программ. Основными вопросами, которые должны рассматриваться составителями SRS, являются: Функциональные возможности; Внешние интерфейсы (Как программный продукт будет взаимодействовать с пользователями, аппаратными средствами системы и другим ПО); Рабочие характеристики (Быстродействие, доступность, время отклика и т.д.); Атрибуты (Каковы мобильность, правильность, удобство сопровождения, защищенность и т.п.); Проектные ограничения, налагаемые на реализацию изделия; Среда SRS Так как SRS играет определенную роль в процессе разработки программного продукта, составителю SRS следует проявить осторожность, чтобы не выйти за пределы этой роли, это означает, что SRS: Должна правильно определять все требования к программному продукту; Не должна описывать детали разработки или реализации; Не должна налагать дополнительные ограничения на программный продукт, они надлежащий образом налагаются в других документах; Характеристика качественной SRS Качественная, правильно составленная SRS должна быть: Корректной, однозначной, Полной, Непротиворечивой, Упорядоченной, Проверяемой, Модифицируемой, Отслеживаемой. Вот такую структуру должна иметь качественная SRS: введение, в котором содержатся ее назначение, область применения, определения и сокращения, публикации и краткий обзор. перспектива изделия, этот раздел должен оценивать изделие в перспективе с другими, связанными изделиями. Если изделие планируется независимым и полностью автономным, то так и должно быть сформулировано в документе, и наоборот, если оно будет являться часть более крупной системы. специфические требования, этот раздел должен содержать все требования в программном продукте на уровне детализации, достаточной, чтобы дать проектировщикам возможность разработать систему, удовлетворяющую этим требованиям, а испытателям – убедиться, что она соответствует этим требованиям. вспомогательная информация, она делает SRS более легкой для использования и должна содержать следующую информацию – содержание, алфавитный указатель, приложения. |