Engenharia de Software I - Exercícios

Capítulo I

1 – A razão é que os sistemas estão cada vez mais complexos e o volume de dados cada vez maior e com freqüentes modificações, com isso dificultando a tomada de decisões através dos dados recolhidos sem um sistema para auxiliar e navegar entre esses dados.
2 - SUMIU! :(
3 – Programas de computador, procedimentos e documentação possivelmente associados e dados relativos ao funcionamento de um sistema computador.
4 - A aplicação de uma sistemática e disciplinada, quantificável para o desenvolvimento, operação e manutenção de software, ou seja, a aplicação da engenharia de software.
5 - Um padrão planejado e sistemático de todas as ações necessárias para fornecer confiança adequada ao software que está em conformidade com os requisitos técnicos estabelecidos. Um conjunto de atividades destinadas a avaliar o processo pelo qual os produtos são desenvolvidos ou fabricados.
6 - O conjunto completo de programas de computador, procedimentos e documentação possivelmente associados e dados designados para entrega a um usuário.
7 – Projeto é uma concepção mental ou idéia de um produto, geralmente representada por modelos. É a representação de um sistema de software criada para facilitar análise,
planejamento e tomada de decisão.
8 - Por Processo entende-se uma série de ações ou passos, planejados cuidadosamente, a serem seguidos pelos desenvolvedores de software, sistematizando, disciplinando e
permitindo gerenciar o desenvolvimento de sistemas computadorizados.
9 – Atividades Executivas são atividades executadas nas fases:
Fase Requisitos do Usuário – RU, Fase Requisitos de Software – RS, Fase Projeto Arquitetural – PA, Fase Projeto Detalhado e Produção – PD, Fase Transferência – TR, Fase Operações e Manutenção – OM.
10 – Atividades Gerenciais são atividades como:
Gerência de Projeto, Gerência de Configuração, Gerência de Verificação e Validação e Gerência de Qualidade.

Capítulo II

1 -
* Fase Requisitos Do Usuario - RU;
* Fase Requisitos Do Software - RS;
* Fase Projeto Arquitetural - PA;
* Fase Projeto Detalhado E Produção - PD;
* Fase Projeto Transferencia - TR;
* Fase Operações E Manutenção - OM;
2 -
* DRU - Documento Requisitos Do Usuário;
* DRS - Documento Requisitos Do Software;
* DRA - Documento Projeto Arquitetural;
* DPD - Documento Projeto Detalhado;
* MUS - Manual Do Usuário;
* DTR - Documento De Transferencia;
* DHP - Documento Historico Do Projeto
3 - Começa quando o DRU é liberado pelo usario para uma revisao formal e termina quando o produto é descartado.
4 - Começa na RS (definição dos requisitos de software) termina no PD (projeto detalhado)
5 - Para os usuários definirem o que eles desejam e para os desenvolvedores definirem o que eles entenderam que o usuário deseja.
6 - Uma abordagem em cascata é adequada quando existe um projeto simples com fases seqüencial, o que torna essa abordagem simplificada e popular, requisitos estáveis e de alta qualidade, a duração do projeto seja de no máximo 2 anos (ou 4000 horas) e permite retomar etapas para correção.
7 - Abordagem incremental é utilizada quando a liberação se faz necessário para estar acordado com os requisitos, fazer integração com sistema já existente ou parte do sistema e oferecer uma prévia que o software será suficiente para resolver o problema.
8 - Abordagem evolucionária é uma série de projetos menores, onde cada projeto aproveita a experiência da liberação anterior e deve ser usada quando requisitos do usuário são de difícil implementação, pois podem depender de tecnologias futuras ou não são totalmente conhecidos, alguns requisitos podem atrasar a liberação do software, portanto necessita um acompanhamento evolucionário para a integração.
9 - Abordagem em cascata é utilizada para o desenvolvimento de software em curto prazo, quando são necessárias apenas pequenas correções e aperfeiçoamento, essas que são feitas na fase de Operação e Manutenção (OP).
10 - A execução simultânea ocorre quando a elaboração do projeto está em andamento e novos requisitos de software são apresentados, resultando em um maior tempo de desenvolvimento e necessidade de uma nova elaboração do projeto. O recomendado para esse projeto seria abordado o Método Cascata com Liberação Incremental.

Capítulo III

1 – O responsável pelo RU é o próprio Usuário junto ao desenvolvedor, onde ele especifica o que o seu sistema deve fazer.
2 – É aceitável desde que o desenvolvedor faça esse documento junto com o usuário e com a aprovação do mesmo.
3 – Os tipos são: Capacidade, Define o que o software deve fazer; Restritivos, Coloca restrições de como o software deve ser construído e operado.
4- Os requisitos do usuário se estruturam da seguinte forma:
– Capturar os Requisitos do Usuário;
– Determinar o ambiente operacional;
– Especificar os Requisitos do Usuário;
– Escrever o Plano dos Testes de Aceitação;
– Escrever os planos para a fase Requisitos de Software;
– Rever os Requisitos do Usuário.
5 – a) O usuário deve ser capaz de gerar relatórios através do software, não o software por si só gerar um relatório.
b) A especificação em relação à boa interface com o usuário está muito genérica, irá depender do ambiente operacional do software.
c) Falhas não é um requisito de usuário, nenhum usuário irá pedir que seu software tenha uma média de falha em 3 horas.
d) Está correto.
e) Este argumento não é um requisito de usuário, é um requisito de software.
6- Cada requisito de usuário deve conter pelo menos as seguintes características: Identificador, Necessidade, Prioridade, Fonte e Estabilidade.
7 – As interfaces para sistemas externos devem estar descritas nas características de restrição no requisito de usuário.
8 – Um sistema com em média 700 requisitos é considerado um sistema de porte Médio enquanto deveria ser desenvolvido com até 20 pessoas.ano, com apenas 2 pessoas.ano pode ser desenvolvido um software de porte pequeno de até 100 requisitos.
9 – O objetivo é sempre mostrar a opção mais adequada para o usuário, mas se o mesmo insistir em utilizar a interface escolhida por ele, assim deve ser feito.
10 – Não se deve colocar especificações desse tipo em um documento de requisitos de usuário, deve ser colocado especificações com uma linguagem menos técnica.

Algoritmos e Estruturas de Dados I - Será?

interface estruturaLinear {
// verifica se a estrutura tem elementos
public boolean estaVazia();
// devolve a quantidade de elementos da estrutura
public int tamanho();
// insere um elemento no início da estrutura
public void inserir(Object p0);
// insere um elemento no fim da estrutura
public void inserirCauda(Object p0);
// remove um elemento do início da estrutura
public Object remover();
// remove um elemento do fim da estrutura
public Object removerCauda();
}

/****************/

public class ArrayCircularList implements estruturaLinear {
protected Object[] array;
protected int start,end,number;

public void pArrayList(int maxsize){
array = new Object[maxsize];
start = end = number = 0;
}
public boolean estaVazia(){
return number == 0;
}
public boolean isFull(){
return number >= array.length;
}
public int tamanho(){
return number;
}
public void inserir(Object o){
if(number < array.length){
array[start = (++start % array.length)] = o;
number++;
}
}
public void inserirCauda (Object o){
if(number < array.length){
array[end] = o;
end = (--end + array.length) % array.length;
number++;
}
}
public Object remover(){
if(estaVazia())
return null;
number--;
int i = start;
start = (--start + array.length) % array.length;
return array[i];
}
public Object removerCauda(){
if(estaVazia())
return null;
number--;
return array[end = (++end % array.length)];
}
}