Engenharia de Software 2006/2007

Transcrição

1 Instituto Superior Técnico Engenharia de Software 2006/2007 Segundo Teste (perguntas 5-10, 70 minutos) Primeiro Exame (perguntas 1-10, 120 minutos) 29/6/2007 Nome: Número: Escreva o seu número em todas as folhas do teste. O tamanho das respostas deve ser limitado ao espaço fornecido para cada pergunta. Pode usar os versos das folhas para rascunho. A cotação de cada questão encontra-se indicada entre parêntesis. Boa sorte. 1. (1.0) A Engenharia de Software aborda diversas qualidades do produto. Descreva e discuta essas várias qualidades. O desenvolvimento de software produz diversos tipos de artefactos, incluindo requisitos, desenhos, programas, testes, etc, e, para cada um destes artefactos, deve-se avaliar a qualidade. Essa avaliação pode ser feita usando o modelo Boehm que se baseia na ideia de que a utilidade de um sistema depende da perspectiva: para um utilizador, o sistema tem qualidade se for fiável, eficiente e com facilidade de utilização, etc.; para um cliente, o sistema deve ser portável, etc; para a equipa de manutenção, o sistema deve ser fácil de testar, de compreender e modificar, etc.

2 Número: 2 2. (1.0) Qual a diferença entre arquitectura e desenho? Discuta as características de cada um. A arquitectura é uma descrição do que o sistema faz e está orientada para o cliente. A arquitectura descreve as funções do sistema e está relacionada com os documentos de requisitos. O desenho é uma descrição de como o sistema faz e está orientada para a equipa de desenvolvimento. O desenho descreve os principais algoritmos, as estruturas e os fluxos de dados.

3 Número: 3 3. (1.0) Diga onde é que no padrão de desenho Data Access Object se verificam as qualidades de ligação fraca e de coesão forte. Justifique. Existe ligação fraca entre os objectos de negócio e as fontes de dados pois o DataAccessObject encapsula os acessos à fonte de dados. Existe coesão forte no DataAccessObject pois agrega todas as funções específicas de acesso às fontes de dados.

4 Número: 4 4. (1.0) O modelo unificado contém pequenos modelos em cascata. Diga em que etapa do modelo unificado isso acontece e justifique porque é que nesse contexto os problemas de utilizar o modelo cascata não têm impacto. Na etapa de Construção existem pequenas iterações de implementação de funcionalidades por preenchimento da arquitectura. Cada uma destas iterações pode ser visto como um processo em cascata pois faz o levatamento de um conjunto de funcionalidades e procede à sua implementação e teste. Esta abordagem não sofre dos problemas do modelo cascata clássico pois cada uma das iterações é de duração muito curta pelo que os ciclos de retro-alimentação podem acontecer entre iterações.

5 Número: 5 5. (1.0) Quais são as qualidades importantes nos requisitos? Explique-as. As qualidades importantes são: Coerência não devem ser ambíguos ou incoerentes. Completude todos os possíveis estados, alterações de estados, entradas, etc, devem ser descritos. Realismo o que é pedido pelo cliente deve ser realizável Clareza a descrição dos requisitos deve ser simples e clara para os utilizadores Validade o requisito deve descrever algo que é de facto relativo ao problema Certificação deve ser possível escrever testes que demonstram que o requisito foi satisfeito Rastreabilidade deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito

6 Número: 6 6. (1.0) Indique como é que no processo de levantamento de requisitos RAPPel se identificam as regras de negócio. As regras identificam-se nas restrições aos casos de uso, aos objectos e ao estado dos objectos.

7 Número: 7 7. (1.0) Quais as formas de organização de equipas que conhece? Em que circunstâncias as utilizaria? Explique. Fundamentalmente, existe a equipa plana e a equipa hierárquica, embora possam existir combinações das duas, i.e., hierárquica até um certo nível de profundidade e plana daí para baixo. Na equipa plana, todos os membros são líderes da equipa, havendo muita comunicação entre eles e sendo o código pertença de todos. Esta equipa é boa para projectos de pequena dimensão e elevada indefinição e onde se exige elevada qualidade e elevada produtividade. Na equipa hierárquica existe um líder que delega competências em sublíderes que delegam competências em sub-sub-líderes até chegar aos elementos mais abaixo na hierarquia. Esta forma de organização de equipas reduz a comunicação necessária e é boa para projectos estáveis, repetitivos e de grande dimensão e que requerem equipas com muitos elementos.

8 Número: 8 8. (1.0) Diga duas situações em que se deve, nas gestão de configurações de software, criar sequências de código diferentes da sequência principal. Justifique? Duas de entre: Criar uma versão privada onde o programador possa tirar partido do sistema de controlo de versões para as suas tarefas individuais. Criar uma sequência de entrega onde é feita a manutenção da versão entregue de forma independente da sequência onde se estão a desenvolver novas versões. Criar uma sequência de preparação para entrega onde se procura estabilizar o código para ser entregue de forma independente do restante desenvolvimento em que a restante equipa continua envolvida. Cria-se um ramo para uma tarefa de longa duração que é muito disruptiva do restante desenvolvimento, pois traz alterações significativas a uma sequência de código, impedindo a sua fácil estabilização.

9 Número: 9 9. (1.0) Durante o desenvolvimento de software há diversas categorias de testes que é necessário realizar. Que categorias são essas? Explique-as. Testes de Unidade, que verificam a funcionalidade dos componentes para os diversos tipos de entradas. Teste de Integração, que verificam se os componentes funcionam conjuntamente como especificado no desenho do sistema Teste da Funcionalidade, que verificam se as funcionalidades descritas na especificação de requisitos são executadas pelo sistema integrado Teste da Não-Funcionalidade, que verificam se o sistema integrado satisfaz os requisitos não-funcionais. Teste de Aceitação, que verificam se os requisitos do utilizador/cliente estão de acordo com o documento de requisitos. Teste de Instalação, que verificam se o sistema funciona no ambiente onde será usado.

10 Número: (1.0) Partindo do princípio que não é possível testar tudo, por exemplo, devido a limitações de tempo ou orçamento, que estratégias seguiria para identificar as partes do sistema onde há maior probabilidade de haver erros? Deve-se tentar testar as interfaces que foram desenvolvidas por terceiras partes e que ninguém na equipa terá tendência a não se sentir responsável pelo seu correcto funcionamento. Deve-se procurar na documentação as partes onde há ambiguidades pois provavelmente foram interpretadas de forma menos correcta pelos programadores e são sujeitas e ter mais erros. Utilizar relatórios passados para identificar áreas onde os problemas ocorrem pois estes têm tendência a voltar a ocorrer nas mesma área.