Requisitos e Validação de Requisitos

Prévia do material em texto

...............................................................................................................................
ENGENHARIA DA COMPUTAÇÃO – módulo 5 N2
MARCOS ALEXANDRE BORGES BARBOSA – RA 
PORTFÓLIO
ENGENHARIA DE SOFWARE
 
...............................................................................................................................
Guarulhos
2015
PORTFÓLIO
ENGENHARIA DE SOFWARE
MARCOS ALEXANDRE BORGES BARBOSA – RA 
 
Trabalho apresentado ao Curso (Engenharia da Computação) da Faculdade ENIAC para a disciplina [Engenharia Sofware].
Prof.
Guarulhos
2015
ATIVIDADE PROPOSTA
1. O que é um requisito? 
RESPOSTA
 O conceito de requisito é também utilizado formalmente na ciência de computação, engenharia de software e engenharia de sistemas, referindo-se à definição de uma característica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus módulos e subrotinas) deve necessariamente prover para ser útil a seus usuários.
Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos;As descrições das funções e restrições são os requisitos do sistema;
Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real;
Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto
2. O que são requisitos de domínio? 
RESPOSTA
São requisitos derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Dois exemplos de requisitos do domínio são:
O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3) /5;
Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos
3. O que é o estudo de viabilidade? 
RESPOSTA
 Estimativa dos investimentos necessários à implantação de projetos e de custos operacionais. Faz-se através de análises técnico-econômico-financeiras, da definição de localização da empresa e do estabelecimento do esquema de captação de recursos humanos.
4. Qual a função da validação de requisitos? 
RESPOSTA
Demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.
À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos
A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erro traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.
Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:
Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.
Consistência: não devem existir conflitos entre os requisitos identificados.
Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.
Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.
Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.
Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.
5. O que define a limitação da complexidade?
RESPOSTA
O custo da complexidade não é linear, é exponencial,e o custo da complexidade acaba por fim dominando todos os outros custos na maioria dos sistemas de sofware.Um codigo complexo é frágil e se quebra facilmente, tornando quase impossivel modificalo-lo de forma segura.Empresas de desenvolvimento de sofwares sensatas colocam no topo a prioridade de manter a base do codigo simples, limpa e pequena.
 
6. Como devem ser as histórias nos testes de aceitação?
RESPOSTA
Cada história deve ter valor de negócio na visão do cliente e é uma pequena parte da funcionalidade, não necessariamente uma especificação completa, o que minimiza a necessidade de uma extensa documentação.
A história de usuário é escrita pelo próprio cliente e, também, serve para conduzir a criação de teste de aceitação, o qual tem o propósito de avaliar a qualidade externa do produto e, na medida do possível, a qualidade de uso e experiência do usuário. A automatização dos testes de aceitação é criada para certificar de que a história foi implementada corretamente
 
7. No que o XP é baseado?
RESPOSTA
Comunicação: A má comunicação é motivo de insucesso em quase todo tipo de projeto, inclusive nos projetos de software. Logo, este é um dos valores mais importantes do XP, bem como das metodologias ágeis como um todo. Esta comunicação deve fluir constantemente através das técnicas a serem aplicadas no processo de desenvolvimento;
Simplicidade: Manter a simplicidade é difícil e é um dos princípios do XP advindos do JIT. Assim, faça a coisa mais simples que pode funcionar, mesmo assim, é um dos princípios mais difíceis de se alcançar, pois somos tentados a fazer algo complexo pensando no futuro, mas é importante lembrar que uma das filosofias do JIT é a eliminação de desperdício, assim, simplicidade é uma obrigação.
Feedback: Muito se fala em feedback na atualidade e aqui ele não é só necessário, como um dos princípios que fazem com que o XP tenha sucesso. Para isso, o uso do TDD passa a ser tão importante, além disso, é importante o feedback do cliente, por isso os ciclos curtos, a integração contínua etc.
Coragem: Este é o último valor do XP, mas não menos importante, pois é necessário ter coragem de jogar um código fora e iniciar do zero, coragem para mudanças. A comunicação nos dá coragem para a mudança, pois temos a noção das reais necessidades do cliente.
Com base nestes valores, temos os princípios do XP.
Os quatro valores geram os princípios básicos do XP, que segundo Kent Beck são:
Feedback rápido através de ciclos curtos (iteração de uma a duas semanas) e comunicação continua (com todos os envolvidos no processo);
Simplicidade presumida, onde deve-se tratar os problemas de forma simples, ou seja, evitar tratar o problema com complexidade, utilizando recursos que nunca serão utilizados, fazendo apenas o necessário;
As mudanças devem ser feitas de forma incremental. Grandes modificações normalmente trazem grandes problemas, então tratar a mudança com ciclos de mudanças curtos é mais eficiente e atendeas bases sistêmicas do paradigma.
Alta qualidade: ninguém gosta de pessoas desleixadas, então a qualidade deve ser sentida não só pelo cliente, mas pela equipe. O teste não é uma opção, é uma obrigação
É um metodo de desenvolvimento de sofware, leve, não é prescritivo, e procura fundamentar as suas práticas por um conjunto de valores que serão vistos posteriormente no artigo. O xp diferentemente do que muitos pensam, também pode se adotar por desenvolvedores médios e não apenas por desenvolvedores experientes.
O objetivo principal é levar ao extremo um conjunto de práticas que são ditas como boas na engenharia de sofware.Entre elas podemos citar o teste, visto que procurar defeitos é perda tempo, nós temos que testar, entre as práticas, o xp diz que:
Já que testar é bom, que todos testem o tempo todo;
Já que revisão é bom, que se revise o tempo todo;
Se projetar é bom, então refatorar o tempo todo;
Se teste de integração é bom, então que se integra o tempo todo;
Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível;
Se iterações curtas é bom,então mantenha-as realmente curtas;
Portanto, como podemos notar todas coisas boas são levadas ao extremo do xp.
 8. Quais os quatro tipos de manutenção?
RESPOSTA
 Corretiva
A manutenção corretiva envolve o desenvolvimento e implantação de soluções de problemas ("bugs") que surgem durante o uso de um programa. Usuários de computador detectam problemas de desempenho com o software, tais como mensagens de erro na tela ou mesmo casos em que o programa trava ou falha, ou seja, a manutenção corretiva é necessária. Muitas vezes, essas correções resolvem definitivamente o problema, mas isso nem sempre acontece. Algumas correções agem como uma solução temporária, enquanto os programadores de computador trabalham com soluções mais permanentes.
Perfectiva
Nenhum software contém zero de falhas ou áreas onde possa melhorar. A manutenção perfectiva envolve programadores que trabalham para melhorar o funcionamento do software ou a sua velocidade de processamento. Os programadores também podem envolver-se em manutenção de software perfectivo para melhorar os layouts do menu do software e interfaces de comando. Às vezes, os programadores precisam realizar a manutenção perfectiva nos softwares por causa de fatores externos, tais como novas regulamentações governamentais que afetam a empresa que o opera.
Adaptativa
O campo da tecnologia muda constantemente através do desenvolvimento de hardwares e softwares. A manutenção adaptativa de softwares aborda estas mudanças. Uma alteração na velocidade de um processador, por exemplo, irá afetar a forma em como o software é executado em um computador. Softwares interagem com outros programas em um computador ou rede, ou seja, mudanças em um programa podem exigir mudanças em outros programas. Um usuário que eventualmente introduza um novo software no computador ou rede pode também afetar a forma como outro software já presente opera.
Preventiva
Quando os programadores de computador se envolvem em manutenção preventiva de softwares eles tentam evitar problemas nos programas antes que eles ocorram. Programadores buscam evitar a manutenção corretiva tanto quanto possível e, ao mesmo tempo, antecipando as necessidades de manutenção de adaptação antes que os usuários relatem problemas. Os programadores testam os programas, assim como as empresas automotivas testam os veículos que fazem, para garantir que o software possa lidar com altas cargas de dados e outras operações estressantes sem problemas. Eles também testam a compatibilidade do software com outros programas que possivelmente estariam presentes no computador para garantir que não ocorram problemas.
 9. O que é abstração? 
RESPOSTA
Abstração é a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software.
10. O que é engenharia de software? 
RESPOSTA
Entendemos engenharia de software como sendo, de acordo com o IEEE, a aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, operação e manutenção de software. Sistemática por que parte do princípio de que existe um processo de desenvolvimento definindo as atividades que deverão ser executadas. Disciplinada por que parte do princípio de que os processos definidos serão seguidos. Quantificável por que se deve definir um conjunto de medidas a serem extraídas do processo durante o desenvolvimento de forma que as tomadas de decisão relacionadas ao desenvolvimento do software (por exemplo, melhoria de processo) sejam embasadas em dados reais, e não em “achismos”
11. O que é tecnologia em camadas?
RESPOSTA
Figura 1
A engenharia de software é uma tecnologia em camadas. De acordo com a Figura 1, qualquer abordagem de engenharia deve se apoiar em um compromisso organizacional com a qualidade.
O alicerce da engenharia de software é a camada de processo. O processo de engenharia de software é o adesivo que mantém unidas as camadas de tecnologia e permite o desenvolvimento racional e oportuno de softwares de computador.
Os processos de software formam a base para o controle gerencial de projetos de software (por exemplo: PMBOK) e estabelecem o contexto no qual:
Os métodos técnicos são aplicados;
Os produtos de trabalho (modelos, documentos, dados, relatórios, entre outros) são produzidos;
Os marcos são estabelecidos,
A qualidade é assegurada;
As modificações são adequadamente geridas.
12. De acordo com as fases de definição, qual o papel da análise de sistemas?
RESPOSTA
É a atividade que tem como finalidade a realização de estudos de processos a fim de encontrar o melhor caminho racional para que a informação possa ser processada. Os analistas de sistemas estudam os diversos sistemas existentes entre hardwares(equipamentos), softwares(programas) e o usuario final.
13. De acordo com as fases de definição, qual o papel da análise de requisitos?
RESPOSTA
Na sistematização e engenharia de software, análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte importante do processo de desenvolvimento de softwares, na qual o engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas estarão preparados para projetar a solução.
A análise de requisitos é a primeira fase de desenvolvimento de software dividido em Requisito funcional e Requisito não-funcional. É nesta fase que o analista faz as primeiras reuniões com os clientes e/ou usuários do software para conhecer as funcionalidades do sistema que será desenvolvido. É nesta fase também que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ou usuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o software terá.
As entrevistas estruturadas são um método utilizado para esta fase e que poderão ter um papel importante na ajuda à compreensão de todas as funcionalidades pretendidas pelo cliente
REFERENCIAS BIBLIOGRAFICAS
https://pt.wikipedia.org/wiki/Requisito
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034
https://www.google.com.br/#q=%22o+que+%C3%A9+o+estudo+de+viabilidade%3F%22
https://pt.wikipedia.org/wiki/Engenharia_de_requisitos
http://tableless.com.br/historia-de-usuario-e-teste-de-aceitacao-em-javascript/
https://pt.wikipedia.org/wiki/Abstra%C3%A7%C3%A3o_(programa%C3%A7%C3%A3o)
http://jkolb.com.br/engenharia-de-software-uma-tecnologia-em-camadas/
http://www.ehow.com.br/tipos-manutencao-software-lista_8959/
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_requerimento_de_softwarehttps://books.google.com.br/books?id=FJZ1mq5Vjo4C&pg=PT84&lpg=PT84&dq=limita%C3%A7%C3%A3o+complexidade+software&source=bl&ots=LOWnQIkZON&sig=xwbMZce9XSpwgUpOegLuGQDtl9A&hl=pt-BR&sa=X&ved=0ahUKEwjGgPjA177LAhWKI5AKHS7oDIwQ6AEISTAI#v=onepage&q=limita%C3%A7%C3%A3o%20complexidade%20software&f=false
http://www.devmedia.com.br/integrando-xp-as-principais-metodologias-ageis/30989