UNIVERSIDADE DA BEIRA INTERIOR Faculdade de Engenharia Departamento de Informática

Transcrição

1 UNIVERSIDADE DA BEIRA INTERIOR Faculdade de Engenharia Departamento de Informática 1ª FREQUÊNCIA 5 abril Engenharia de Software /19, Duração:120 minutos 1. [3 valores] Descreva as principais atividades do processo de desenvolvimento de software e indique como as mesmas se podem relacionar. Especificação - definir o que o sistema deve fazer; Concepção e implementação - define a organização do sistema e implementação do sistema; Validação - verificar se ele faz o que o cliente quer; Evolução - mudança do sistema em resposta às necessidades dos clientes. Critério Avaliação: 0,75 valores cada item. 2. [3.5 valores] Explique por que, em sistemas complexos, as mudanças são inevitáveis. Identifique (pode recorrer a exemplos, se necessário) as atividades de processo de desenvolvimento de software que ajudam a prever as mudanças e fazer com que o software desenvolvido seja mais tolerante a mudanças (desconsidere prototipagem e entrega incremental). Os sistemas devem mudar porque são instalados num ambiente que se adapta a eles e esta adaptação naturalmente gera novos / diferentes requisitos de sistema. Além disso, o ambiente do sistema é dinâmico e gera constantemente novas exigências. A menos que o sistema seja adaptado para refletir estes requisitos, as suas instalações não se sincronizam com as instalações necessárias para suportar o negócio e, portanto, tornam-se menos útil. Exemplos de atividades de processos que suportam a mudança são: 1. Documentar requisitos de modo que seja conhecida a razão pela qual um requisito é incluído. Isto ajuda com mudanças futuras. 2. Rastrear os requisitos para sabermos as dependências entre os requisitos e entre os requisitos e o design e/ou código do sistema; 3. Modelação do projeto onde o modelo de design documenta a estrutura do software. 1

2 4. Rever o código para melhora a qualidade e assim torna-lo mais passível de mudança. Critério Avaliação: Justificação 0,5 valores. Cada exemplo correcto 0,75 valores até ao máximo de 3 valores. 3. [4 valores] Explique como os princípios básicos dos métodos ágeis levam ao rápido desenvolvimento e implantação de software. E indique quando não recomendaria o uso de um método ágil para o desenvolvimento de um sistema de software. Os princípios subjacentes ao desenvolvimento ágil são: Individuais e interações são mais importantes que os processos e ferramentas. Ao compreender as mais valias das habilidade e capacidades individuais e assegurando que a equipa de desenvolvimento sabe o que os restantes colegas estão a realizar fazer, são evitados custos de comunicação formal. Isso significa que a equipa possa concentrar-se no desenvolvimento do software. Software a funcionar é mais importante que documentação completa. Isso contribui para o desenvolvimento acelerado porque o tempo não é gasto em desenvolvimento, verificação e gestão de documentação. Em vez disso, o tempo do programador é focado no desenvolvimento e teste de código. Colaboração com o cliente mais importante que a negociação do contrato. Ao invés de gastar tempo no desenvolvimento, análise e negociação dos requisitos a serem incluídos no contrato, os programadores ágeis argumentam que é mais eficaz obter o feedback dos clientes durante o desenvolvimento. Isso permite que funcionalidade útil possa ser desenvolvida e entregue mais cedo do que seria possível se fossem necessários contratos. Capacidade de resposta a alterações mais importante que seguir um plano. Programadores ágeis argumentam que aceitar a mudança é mais eficaz do que seguir um processo baseado em plano porque a mudança é inevitável qualquer que seja o processo usado. Há sobrecarga significativa na mudança de planos para acomodar a mudança e a inflexibilidade de um plano significa que o trabalho pode ser feito que é mais tarde descartado. Métodos ágeis não devem ser usados quando o software está a ser desenvolvido por equipas que não estão co-localizadas. Se qualquer uma das equipas individuais usar métodos ágeis, é muito difícil coordenar o trabalho com outras equipas. Além disso, é praticamente impossível manter a comunicação informal que é uma parte essencial dos métodos ágeis. Métodos ágeis provavelmente também devem ser evitados para sistemas críticos onde as consequências de um erro de especificação são graves. Nessas circunstâncias, uma especificação de 2

3 sistema disponível antes do início do desenvolvimento torna possível uma análise detalhada das especificações. Critério Avaliação: Justificação da não recomendação 1 valor. Cada principio correcto 0,75 valores até ao máximo de 3 valores. 4. [2.5 valores] Explique os benefícios e limitações da prototipagem no processo de desenvolvimento de software. Benefícios: permitir uma melhor identificação das necessidades dos utilizadores; permitir a validação antecipada relativamente à usabilidade e design do sistema; permitir uma redução do esforço de desenvolvimento. Limitações: Dificuldade ou mesmo impossibilidade de validar requisitos não funcionais (foco nos requisitos funcionais); validação de erros é geralmente omissa no protótipo; documentação escassa ou inexistente; passível de se degradar com a utilização (caso de protótipo de equipamento/dispositivo por exemplo); possibilidade de a qualidade ser inferior ao standard da organização. Critério Avaliação: Cada beneficio ou limitação correcto 0,5 valores até ao máximo de 2,5 valores. Ausência de indicação de pelo menos um beneficio ou limitação: penalização de 0,5 valores. 5. Considere a seguinte declaração de requisitos: Um sistema automatizado para emitir bilhetes de metro. Os utilizadores selecionam o seu destino e inserem um cartão de crédito e um número de identificação pessoal. O bilhete é emitido, e a sua conta de cartão de crédito é cobrada. Quando o utilizador pressiona o botão de início, é ativado um display de menu de destinos possíveis, junto com uma mensagem para selecionar um destino. Uma vez que o destino tenha sido selecionado, os utilizadores são convidados a inserir o seu cartão de crédito. A sua validade é verificada e, em seguida, é solicitada ao utilizador a entrada de um identificador pessoal. Quando a operação de crédito é validada, o bilhete é emitido [2 valores] Identifique ambiguidades ou omissões na declaração de requisitos apresentada. Um cliente pode comprar vários bilhetes juntos para o mesmo destino ou devem ser comprado um de cada vez? Os clientes podem cancelar uma solicitação se um erro foi cometido? Como o sistema deve responder se for usado um cartão inválido? O que acontece se os clientes tentam colocar um cartão antes de selecionar um destino (como reagiriam as máquinas ATM)? 3

4 O utilizador deve premir novamente o botão Start se quiser comprar outro bilhete para um destino diferente? O sistema só pode vender bilhetes entre a estação onde a máquina está situada e as ligações diretas ou deve incluir todos os destinos possíveis? Critério Avaliação: Cada ambiguidade ou omissão correcta 0,5 valores até ao máximo de 2 valores [5 valores] Escreva um conjunto de requisitos funcionais, e requisitos não funcionais para o sistema de emissão de bilhetes. Possível conjunto de requisitos funcionais: RF01: O sistema deverá permitir ao utilizador a escolha da estação de destino de entre uma lista que lhe é apresentada. RF02: O sistema deverá permitir que o utilizador indique o número de bilhetes pretendidos. RF03: O sistema deverá solicitar ao utilizador a introdução do seu código pessoal por forma a validar a transacção. RF04: Em caso de sucesso do requisito RF03, o sistema deverá apresentar ao utilizador uma mensagem para a inserção do cartão de crédito como forma de pagamento. RF05: O sistema deverá solicitar ao utilizador a confirmação da transação, mediante apresentação do número de bilhetes a comprar, e respectivo valor. Possível conjunto de requisitos não funcionais: RFN01: Entre 06:00 e 23:00, o tempo total de inatividade do sistema não deve exceder 5 minutos; RFN02: Entre 06:00 e 23:00, o tempo de recuperação após uma falha do sistema não deve exceder 2 minutos; RFN03: Entre 23:00 e 06:00, o tempo total de inatividade do sistema não deve exceder 20 minutos; RFN04: Depois que o cliente pressionar um botão na máquina, o display deve ser atualizado em 0,5 segundos; RFN05: O tempo de emissão do bilhete após a validação do cartão de crédito não deve exceder 10 segundos; RFN06: Ao validar o cartão de crédito, o display deve apresentar uma mensagem de status aos clientes, onde indica que a atividade está a ocorrer. 4

5 RFN07: A taxa de falha máxima aceitável para pedidos de emissão de bilhetes é de 1: Critério Avaliação: Cada requisito correctamente definido 0,5 valores até ao máximo de 5 valores. Requisito parcialmente correcto 0,25 valores. Inexistência de um dos tipos de requisitos (funcional ou não funcional): penalização de 50% 5