Portfolio Engenharia de Software

[pic 1]

...............................................................................................................................

ANALISE E DESENVOLVIMENTO DE SISTEMA – 5°semestre

ANTONIO LEOMAR ALVES DA SILVA – RA 257082014

Engenharia de software

portfólio

...............................................................................................................................

Guarulhos

2016

ANTONIO LEOMAR ALVES DA SILVA – RA 257082014

Engenharia de software

portfólio

Trabalho apresentado ao Curso de Analise e Desenvolvimento de Sistemas da Faculdade ENIAC para a disciplina  Engenharia de Software

Prof. Denilson Caraça Peramos

...............................................................................................................................

Guarulhos

2016

[pic 2]

Respostas

.............................................................................................................

1.O que é um requisito?

Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado engenharia de requisitos.

2.O que são requisitos de domínio?

São restrições originárias do requisito da aplicação do sistema e refletem as características do mesmo.

3.O que é o estudo de viabilidade?

É a qualidade do que é viável, com fortes probabilidades de se levar a cabo ou de se concretizar por se reunir todas circunstancias /caracteristicas necessárias.

4. Qual a função da validação de requisitos?

A validação é o processo pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer. Ela se sobrepõe a análise, uma vez que está preocupada em encontrar problemas com requisitos. Ela é importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho quando descobertos durante o desenvolvimento ou após o sistema já estar em serviço.

5.O que define a limitação da complexidade?

Na engenharia de software a limitação da complexidade se dá através do desempenho que o software está sendo desenvolvido, se ele é um trabalho amplo, há a necessidade de saber o que fazer, aí entra a engenharia, se ao contrário, é um projeto simples, que qualquer pessoa ainda que não seja da área faz, então não é necessário identificar situações ou necessidades, trata de ver as fases de um sistema que vai desde, análise econômica de sistemas de informações, organização do projeto (incluindo equipes e responsabilidades), estruturação das tarefas (EAP), cronograma do projeto (MS Project), análise e gestão de riscos, até a estimativa de custos, agindo assim, avaliarmos a complexidade.

6.Como devem ser as histórias nos testes de aceitação?

Especifique seus critérios como dado/quando/então, assim: Se você escreve seus critérios de aceitação neste formato, isso não só provém uma estrutura consistente, mas se seus testes de aceitação automatizados também são especificados no formato Dado/Quando/Então, então isso traduz critérios de aceitação em testes de aceitação muito eficientes. Os seus critérios de aceitação são menos propensos a serem nebulosos como se pensa quando seguindo este formato consistente, com uma pré-condição, ação e resultado esperado.

* Este formato foi escrito pela primeira vez por Dan North, em 2007, e alguma vezes é referenciado (incorretamente) como a linguagem Gherkin, que é específica da ferramenta Cucumber. Você deve especificar seus critérios de aceitação como checklists Ter os critérios de aceitação especificados para uma história de usuário em um formato de checklist faz dos critérios de aceitação claros e concisos, visto que nada mais é necessário. Cenários do tipo Dado/Quando/Então podem ser verbosos e difíceis de ler em um cartão de história de usuário. Isso também significa que eles são fáceis de individualmente serem marcados como completos enquanto os programadores implementam a funcionalidade (em uma ferramenta como o Trello). O maior benefício é que checklists de critérios de aceitação não podem ser transferidos diretamente da história de usuário à um teste de aceitação automatizado. Isto é importante porque os critérios de aceitação das funcionalidades não devem replicar histórias de usuário: uma história de usuário é uma mudança para um sistema, uma funcionalidade é uma coleção de coisas que ele faz. Então, ter uma funcionalidade para cada história de usuário é um desastre, o que é mais provável de acontecer se os critérios de aceitação estão no formado Dado/Quando/Então. Ter seus critérios de aceitação em formato de checklists também significa que há algum pensamento humano sobre como implementar uns testes de aceitação. Pode ser que um cenário de testes de aceitação cubra três itens de critérios de aceitação do checklist, que é como deveria ser feito, não simplesmente um mapeamento um para um, o que pode acontecer quando se usa o formado Dado/Quando/Então para ambos critérios de aceitação e testes.

7. No que o XP é baseado?

Extreme Programming (XP) é uma metodologia de desenvolvimento de software que se destina a melhorar a qualidade do software e capacidade de resposta à evolução das necessidades dos clientes. Como um tipo de desenvolvimento ágil de software, defende "releases" frequentes em ciclos curtos de desenvolvimento, que se destina a melhorar a produtividade e introduzir pontos de verificação a que as novas exigências dos clientes podem ser adotadas.

Outros elementos da programação extrema incluem: programação em pares ou fazer uma extensa revisão de código, testes de unidade de todo o código, evitando a programação de recursos até que eles são realmente necessários, uma estrutura de gestão plana, simplicidade e clareza no código, esperando mudanças nos requisitos do cliente como o tempo passa e que o problema seja melhor compreendido, e comunicação frequente com o cliente e entre os programadores. A metodologia leva o seu nome a partir da ideia de que os elementos benéficos de práticas de engenharia de software tradicionais são levados a "extrema "níveis. Como exemplo, revisões de código são considerados uma prática benéfica; levada ao extremo, o código pode ser revisto de forma contínua, ou seja, a prática de programação em pares.