Duração: 80 min min. tolerância. Qualquer tipo de fraude implica a reprovação da Unidade Curricular;

Transcrição

1 Engenharia de Software 2017/ o Ciclo de Engenharia Informática 1 o Ciclo de Tecnologias e Sistemas da Informação 1 o Ciclo de Informática Web 2 o Ciclo de Engenharia Eletrotécnica e de Computadores Nome: Correção da Prova Escrita P1 09/04/2018 Número de Aluno: Duração: 80 min min. tolerância Qualquer tipo de fraude implica a reprovação da Unidade Curricular; A prova escrita tem uma duração máxima de 80 minutos, mais 10 minutos de tolerância; Para a realização desta prova o estudante não está autorizado pelo regente da Unidade Curricular a consultar os seus apontamentos em papel ou em formato digital, a não acatação desta regra resulta na imediata reprovação do estudante à Unidade Curricular; Esta prova escrita é composta por cinco grupos de questões, sendo que em cada grupo, o estudante apenas responde a duas questões. Boa Sorte!!!

2 07/02/ / 7 Grupo I (0,5 + 0,5) A. Quais são os quatro atributos importantes que todo o software profissional deve possuir? Sugira outros quatro atributos que, às vezes, podem ser significantes. Quatro atributos importantes : manutenção, confiabilidade (confiável), desempenho e usabilidade. Outros atributos que podem ser significativos: reutilização (ele pode ser reutilizado em outras aplicações), distribuído (ele pode ser distribuído através de uma rede de processadores), portabilidade (pode operar em múltiplas plataformas por exemplo, portáteis e plataformas móveis) e inter-operabilidade (ele pode trabalhar com uma ampla gama de outros sistemas de software). B. Além dos desafios de heterogeneidade, mudanças sociais e corporativas, confiança e proteção, identifique outros problemas e desafios que a engenharia de software provavelmente enfrentará num futuro próximo (Dica: pense no meio ambiente). Desenvolvimento de sistemas que são eficientes em termos energéticos. Estes sistemas tornam-se mais utilizáveis em dispositivos móveis de baixa potência e ajuda a reduzir a pegada global do carbono dos equipamentos de TI; Desenvolvimento de técnicas de validação para sistemas de simulação (que será essencial para prever a extensão e planear a mudança climática); Desenvolvimento de sistemas para uso multicultural; Desenvolvimento de sistemas que podem ser adaptados rapidamente às novas necessidades de negócio; Desenvolvimento de sistemas que são resistentes ao ataque; Desenvolvimento de sistemas que podem ser adaptados e configurados pelos utilizadores finais; Encontrar formas de testes, validação e manutenção de sistemas desenvolvidos. C. Para ajudar a combater o terrorismo, muitos países planeiam desenvolver, ou já desenvolveram, sistemas computacionais que rastreiam grandes números de cidadãos e as suas ações. Obviamente, isso tem implicações nas questões da privacidade. Discuta a ética de se trabalhar desenvolvendo esse tipo de sistema.

3 07/02/ / 7 Grupo II (0,5 + 0,5) A. Justificando a sua resposta com base no tipo de sistema a ser desenvolvido, sugira o modelo genérico de processo de software mais adequado para ser usado como base para a gestão do desenvolvimento dos seguintes sistemas: Um sistema para controlar o anti-bloqueio de travagem de um carro. Este é um sistema crítico de segurança que requer muita análise antes da implementação. Certamente precisa de uma abordagem orientada para o plano de desenvolvimento com os requisitos cuidadosamente analisados. Um modelo em cascata é a abordagem mais adequada, talvez com transformações formais entre os diferentes estágios de desenvolvimento. Um sistema de realidade virtual para dar apoio à manutenção de software. Este é um sistema onde os requisitos mudam e haverá uma extensa componentes de interface de utilizador. Desenvolvimento incremental com, talvez, alguns protótipos UI é o modelo mais adequado. Pode ser utilizado um processo ágil. Um sistema de contabilidade para uma universidade, que substitua um sistema já existente. Este é um sistema cujos requisitos são bastante conhecidos e que será utilizado num ambiente em conjunto com muitos outros sistemas. Portanto, uma abordagem baseada em reutilização é apropriada. Um sistema interativo de planeamento de viagens que ajude os utilizadores a planear viagens com menor impacto ambiental. Sistema com uma interface de utilizador complexa, mas que deve ser estável e confiável. Uma abordagem de desenvolvimento incremental é o mais adequado, como os requisitos do sistema vão mudando, a experiência do utilizador com o sistema também vai sendo adquirida. B. Descreva as principais atividades do processo de projeto de software e as saídas dessas atividades. Usando um diagrama, mostre as possíveis relações entre as saídas dessas atividades. Especificação - definir o que o sistema deve fazer; Conceçã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. C. Explique por que, em sistemas complexos, as mudanças são inevitáveis. Exemplifique as atividades de processo de software que ajudam a prever as mudanças e fazer com que o software seja desenvolvido 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. 4. Rever o código para melhora a qualidade e assim torna-lo mais passível de mudança.

4 07/02/ / 7 Grupo III (0,5 + 0,5) A. Explique como os princípios básicos dos métodos ágeis levam ao rápido desenvolvimento e implantação de software. E 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 sobre processos e ferramentas. Ao compreender as mais valias das habilidade e capacidades individuais e assegurando que a equipa de desenvolvimento sabe o que o outro está a fazer, são evitados custos de comunicação formal. Isso significa que a equipa possa concentrar-se no desenvolvimento do software. Software que trabalha sobre uma 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 do cliente na 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. Respondendo à mudança na sequência de 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 sistema disponível antes do início do desenvolvimento torna possível uma análise detalhada das especificações. B. Sugira quatro razões pelas quais a taxa de produtividade de programadores que trabalham em pares (equipa) pode ser mais que a metade da taxa de produtividade de dois programadores que trabalham individualmente. A programação dos pares conduz à revisão informal contínua. Isso descobre bugs mais rapidamente do que o teste individual; Partilha de informações na programação em equipa é implícito - isso acontece durante o processo. Assim, reduz a necessidade de documentação e o tempo necessário, se um programador tiver que pegar o trabalho de outro. Programadores individuais têm de gastar tempo para partilhar informações e assim eles não estão a ser produtivos; A programação de pares incentiva a refatoração (o código deve ser compreensível a uma outra pessoa). Isto reduz os custos do desenvolvimento e da subsequente mudança e significa que as mudanças futuras podem ser feitas mais rapidamente. Consequentemente, aumenta a eficiência. Na programação em pares, as pessoas gastam menos tempo na otimização porque este não beneficia o outro programador. Isto significa que os pares focalizam nas características essenciais do sistema e podem então produzir mais rapidamente.

5 07/02/ / 7 C. Tem-se sugerido que um dos problemas de se ter um utilizador a integrar uma equipa de desenvolvimento de software é que eles "se tornam nativos", ou seja, adotam a perspetiva da equipa de desenvolvimento e perdem de vista as necessidades dos seus colegas utilizadores. Sugira três maneiras de evitar esse problema e discuta as vantagens e desvantagens de cada abordagem. Envolvem vários utilizadores na equipe de desenvolvimento. As vantagens são obter múltiplas perspetivas sobre o problema, melhor cobertura das tarefas dos utilizadores (requisitos) e, portanto, menos probabilidade de ter um utilizador atípico. Desvantagens são o custo, dificuldades de obter o envolvimento do utilizador e possíveis conflitos de utilizadores; Alterar o utilizador que está envolvido com a equipa. As vantagens são, mais uma vez, múltiplas perspetivas. Desvantagens são que cada utilizador leva tempo para ser produtivo e possíveis conflitos de requisitos de diferentes utilizadores. Valide as sugestões do utilizador com outros utilizadores. Vantagens são verificação independente de sugestões; desvantagem é que isso retarda o processo de desenvolvimento, uma vez que leva tempo a fazer as verificações. Grupo IV (0,5 + 0,5) A. Descubra ambiguidades ou omissões nas seguintes declarações de requisitos para parte de um sistema de emissão de bilhetes: Um sistema automatizado para emitir bilhetes vende 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. As ambiguidades e omissões incluem: Um cliente pode comprar vários bilhetes juntos para o mesmo destino ou devem ser comprados 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)? 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?

6 07/02/ / 7 B. Escreva um conjunto de requisitos não funcionais para o sistema de emissão de bilhetes, definindo a sua confiabilidade e tempo de resposta esperados. Os requisitos não funcionais possíveis para o sistema de emissão de bilhetes incluem: Entre 06:00 e 23:00, o tempo total de inatividade do sistema não deve exceder 5 minutos; Entre 06:00 e 23:00, o tempo de recuperação após uma falha do sistema não deve exceder 2 minutos; Entre 23:00 e 06:00, o tempo total de inatividade do sistema não deve exceder 20 minutos; Depois que o cliente pressionar um botão na máquina, o display deve ser atualizado em 0,5 segundos; O tempo de emissão do bilhete após a validação do cartão de crédito não deve exceder 10 segundos; 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. A taxa de falha máxima aceitável para pedidos de emissão de bilhetes é de 1: C. Quando mudanças urgentes precisam ser feitas em sistemas, o software do sistema pode precisar ser modificado antes de serem aprovadas as mudanças nos requisitos. Sugira um modelo de um processo para fazer essas modificações de modo a garantir que o documento de requisitos e implementação do sistema não se tornem inconsistentes. O processo deve atribuir uma prioridade às alterações, para que as alterações de emergência sejam feitas, essas alterações devem ter prioridade quando se trata de fazer modificações para os requisitos do sistema. O código alterado deve ser um contributo para o processo de mudança final. Contudo, pode ser o caso de que a melhor forma de fazer a alteração, pode ser encontrada quando mais tempo está disponível para análise essa mudança. Grupo V (0,5 + 0,5) A. Como poderia usar um modelo de um sistema que já existe? Explique por que nem sempre é necessário que um modelo de sistema seja completo e correto. O mesmo seria verdadeiro caso se estivesse a desenvolver um modelo de um novo sistema? Pode-se criar e usar um modelo de um sistema que já existe pelas seguintes razões: Compreender e documentar a arquitetura e o funcionamento do sistema existente; Atuar como foco de discussão sobre possíveis mudanças nesse sistema; Informar a re-implementação do sistema. Não é preciso um modelo completo, a menos que a intenção seja documentar completamente o funcionamento do sistema existente. O objetivo do modelo em tais casos é geralmente para ajudar a trabalhar em partes do sistema para que só estes precisem de ser modelados. Além disso, se o modelo é usado como um foco de discussão, é improvável que exista interesse em detalhes e assim pode-se ignorar partes do sistema no modelo. Isso é verdade, em geral, para modelos de novos sistemas, a menos que uma abordagem baseada em modelo para o desenvolvimento esteja a ocorrer, caso em que um modelo completo é necessário. As outras circunstâncias em que se pode precisar de um modelo completo é quando há uma exigência contratual para que seja produzido um modelo para a documentação do sistema.

7 07/02/ / 7 B. Desenvolva um diagrama de sequência que mostre as interações envolvidas quando um estudante se regista para um curso em uma universidade. Os cursos podem ter a inscrição limitada, então o processo de registo deve incluir verificações de vagas disponíveis. Suponha que o estudante acesse a um catálogo digital de cursos para saber mais sobre os cursos disponíveis. C. Olhe atentamente como as mensagens e caixas de correio eletrónico são representadas no sistema de que se usa. Modele as classes de objetos que poderiam ser usadas na implementação do sistema para representar uma caixa de correio eletrónico e uma mensagem de correio. D. Um gestor de engenharia de software e a sua equipa propõe que a engenharia dirigida a modelos deve ser usada para desenvolver um novo sistema. Que fatores se deve levar em conta ao decidir se deve ou não introduzir essa nova abordagem ao desenvolvimento de software? Experiência da equipa no uso de UML. (Poderá ser necessário formação.) Os custos e a funcionalidade das ferramentas disponíveis para desenvolvimento; A vida útil provável do software que se está a desenvolver; Requisitos para o alto desempenho; Os benefícios a longo prazo; O entusiasmo dos programadores de software. (todos os membros da equipa estão comprometidos com esta nova abordagem)