Documente Academic
Documente Profesional
Documente Cultură
DE
SOFTWARE
REFERÊNCIA
2) Modelo Espiral
• Combina a natureza iterativa da prototipagem com aspectos consolidados e
sistemáticos do modelo em cascata;
3) Modelo de Desenvolvimento Concorrente
• É aplicável a todos os tipos de desenvolvimento de software e fornece
uma imagem precisa do estado atual do projeto;
4) Desenvolvimento Ágil
W5HH
• Porque o sistema está sendo desenvolvido (Why);
• O que será feito (What);
• Quando será concluído (When);
• Quem será o responsável por uma função (Who);
• Onde estão localizados na organização (Where);
• Como o trabalho será conduzido técnica e gerencialmente (How);
• Quanto é necessário de cada recurso (How Much)
6) Engenharia de Sistemas
7) Engenharia de Requisitos
8) Modelagem de Análise
9) Engenharia de Projeto
10) Projeto Arquitetural
11) Projeto no nível de Componentes
12) Projeto de Interface com o usuário
13) Estratégias de Testes de Software
14) Técnicas de Teste de Software
15) Métricas de Projeto de Software
TÓPICOS GERAIS
1) Processo Unificado
2) Engenharia de Requisitos
LISTA 01
LISTA 02
LISTA 03
Com base nessa planilha e com relação aos conceitos de dado, informação e
conhecimento, julgue os itens que se seguem.
A - I e II.
B - I e IV.
C - II e III.
D - II e IV.
E - III e IV.
10) O objetivo da Teoria Geral dos Sistemas (TGS) é a formulação dos princípios
válidos para os sistemas em geral, qualquer que seja a natureza dos elementos que
os compõem e as relações ou forças existentes entre eles. Na área de sistemas de
informação, diversos problemas requerem abordagem multidisciplinar para serem
resolvidos. Por exemplo, na área de desenvolvimento de software, a especificação
de requisitos apresenta vários desafios desse tipo, tais como aspectos de
relacionamento interpessoal, conhecimento do negócio, resolução de conflitos,
diferenças culturais etc. Os propósitos da TGS que podem contribuir para a
resolução desses problemas incluem
I- o incentivo à especialização total das áreas do conhecimento.
II- o desenvolvimento dos princípios unificadores quetranscendem o universo das
ciências individuais.
III- a integração de contribuições de várias ciências na busca de solução dos
problemas.
IV - o desenvolvimento de princípios únicos para cada área do conhecimento.
V - o desenvolvimento de estudos que visem à ampliação da separação entre as
ciências naturais e sociais. Estão certos apenas os itens:
A) I e II.
B) I e V.
C) II e III.
D) III e IV.
E) IV e V
R.:
O CMMI (Capability Maturity Model Integration) é um modelo de referência que
contém práticas (Genéricas ou Específicas) necessárias à maturidade em
disciplinas específicas (Systems Engineering (SE), Software Engineering (SW),
Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).
Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie
Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único
para o processo de melhoria corporativo, integrando diferentes modelos e
disciplinas.
A versão atual do CMMI (versão 1.2) apresenta três modelos:
▪ CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao
processo de desenvolvimento de produtos e serviços.
▪ CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se
aos processos de aquisição e terceirização de bens e serviços.
▪ CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. Dirige-se aos
processos de empresas prestadoras de serviços.
R.:
Possibilita à organização utilizar a ordem de melhoria que melhor atende os
objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade
(Capability Levels):
▪ Nível 0: Incompleto (Ad-hoc)
▪ Nível 1: Executado (Definido)
▪ Nível 2: Gerenciado / Gerido
▪ Nível 3: Definido
▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
▪ Nível 5: Em otimização (ou Optimizado)
R.:
Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios
que não deve ser desconsiderada, pois cada estágio serve de base para o próximo.
É caracterizado por Níveis de Maturidade (Maturity Levels):
▪ Nível 1: Inicial (Ad-hoc)
▪ Nível 2: Gerenciado / Gerido
▪ Nível 3: Definido
▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
▪ Nível 5: Em otimização
26) Em que consiste a Engenharia de Requisitos?
R.:
é um processo que engloba todas as atividades que contribuem para a produção de
um documento de requisitos e sua manutenção ao longo do tempo.
Este processo deve ser precedido de estudos de viabilidade que, a partir das
restrições do projeto, determinam se este é ou não viável e se deve prosseguir para
a identificação dos requisitos.
R.:
O processo de engenharia de requisitos é composto por quatro atividades de alto
nível (Soares, 2005):
1. Identificação.
2. Análise e negociação.
3. Especificação e documentação.
4. Validação.
Uma outra atividade que se pode considerar que faz também parte deste processo,
se incluirmos a fase posterior à produção do documento (isto é, a sua
"manutenção"), é a gestão dos requisitos (change management, sendo que as
alterações podem ser causadas pelos mais diversos fatores desde inovações
tecnológicas a mudanças na natureza do negócio (e consequentemente nos
requisitos), entre outras).
R.:
Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto,
deve ser feito um estudo de viabilidade.
Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de
vista tecnológico e organizacional, o projeto é viável.
Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com
"as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou
entrevistas, por exemplo), a resposta às seguintes questões:
▪ Será que o sistema contribui para os objetivos da organização?
▪ Dadas as restrições tecnológicas, organizacionais (econômicas, políticas,
ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o
sistema pode ser implementado?
▪ Caso haja necessidade de integração entre diferentes sistemas, será que esta é
possível?
29) Em que consiste um estudo etnográfico?
R.:
Os Estudos Etnográficos são uma análise da componente social das tarefas
desempenhadas numa dada organização. Quando um dado conjunto de tarefas se
torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular
todos os passos que segue ou todas as pessoas com as quais interage para as
levar a cabo. Através de uma observação direta das atividades realizadas durante
um período de trabalho de um funcionário é possível encontrar requisitos que não
seriam observáveis usando técnicas convencionais. Esta observação pode ser
acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia
visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica
assume-se que o representante do cliente observado desempenha as suas funções
"corretamente", pelo que convém ter algum cuidado na escolha do mesmo.
R.:
Segundo Babich [BABICH86] gestão de configuração de software é:
“A arte de coordenar o desenvolvimento de software para minimizar a confusão é
chamada de
gestão de configuração. A gestão de configuração é a arte de identificar, organizar
e controlar
modificações de software que está sendo construído por uma equipe de
programação. O objetivo é
maximizar a produtividade pela minimização dos erros.”
R.:
Brown e Wallnau[3] descrevem um componente como "uma não-trivial, quase
independente, e substituível parte de um sistema que cumpre uma função clara no
contexto de uma arquitetura bem definida". Em muitos sentidos, esta descrição é
similar a de um objeto em POO. Componentes possuem uma interface. Eles
empregam regras de herança.
Já para Szyperski [4], o componente não é necessariamente uma tecnologia
implementada especificamente e nem a aplicação, mas sim um dispositivo de
software que possua uma interface bem definida.
Mas para Krutchen [5], o componente é um elemento independente, que pode ser
substituído, contudo, ele é significativo, pois tem uma função clara no contexto em
que foi definido.
Mas a definição é levada ainda além. Componentes são definidos para oferecer um
certo nível de serviço. No caso dos componentes "comerciais de prateleira" ( ou
commercial off-the-shelf - COTS), o engenheiro de software sabe pouco ou nada
sobre o funcionamento interno de um componente. Ao invés disso, ao engenheiro
de software é dada apenas uma interface externa bem-definida a partir da qual ele
deve trabalhar. O nível de serviço é portanto crucial e precisa ser acurado se quiser
que a integração do componente ao sistema de software seja bem sucedida. Brown
e Wallnau descrevem um componente de software como “uma unidade de
composição contratualmente especificada e somente com dependências contextuais
explícitas”. Ao contrário de objetos em POO, os componentes são usualmente
construídos a partir de muitos “objetos” de software (embora a construção não seja
confinada a POO) e fornecem uma unidade de funcionalidade coerente. Os assim
chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em
um dado nível de serviço. Componentes podem ser caracterizados com base em
seu uso no processo de ESBC: Como mencionado acima temos os COTS. São
componentes que podem ser comprados, pré-fabricados, com a desvantagem de
que, no geral, não há código fonte disponível, e sendo assim, a definição do uso do
componente dada pelo fabricante(desenvolvedor), e os serviços que este oferece,
precisam ser confiavelmente testadas, como podem ou não ser acuradas. A
desvantagem, entretanto, é que estes tipos de componentes deveriam(em teoria)
ser mais robustos e adaptáveis, pois foram usados e testados( e reusados e re-
testados) e muitas diferentes aplicações. Adicionalmente aos COTS, a ESBC
almeja:
▪ Componentes qualificados [6]
▪ Componentes adaptados
▪ Componentes aglutinados
▪ Componentes atualizados
33) Quais os 2 processos que correm em paralelo na ESBC?
R.:
a) Engenharia de Domínio
Objetiva identificar, construir, catalogar e disseminar um conjunto de componentes
de software que tenham aplicabilidade para software existentes e futuros, dentro de
um domínio de aplicação específico. Um domínio de aplicação é como uma família
de produtos - aplicações com funcionalidade(ou intenção de funcionalidade) similar.
O objetivo é estabelecer um mecanismo em que engenheiros de software possam
partilhar estes componentes usando-os em sistemas futuros.
b) Desenvolvimento Baseado em Componentes
O Desenvolvimento Baseado em Componentes (DBC) aborda a criação de sistemas
de software que envolva a composição de componentes permitindo a adição,
adaptação, remoção e substituição de partes do sistema sem a necessidade de sua
completa substituição. Isso auxilia na manutenção dos sistemas uma vez que,
permite a integração de novos componentes e/ou a atualização dos já existentes. A
abordagem é criar ou adaptar os componentes para que sejam utilizados em
diversos sistemas. Essa idéia vem ao encontro da reutilização que busca flexibilizar
o desenvolvimento.
R.:
• De acordo com a Natureza
◦ Riscos de Projeto
◦ Riscos de Negócio
◦ Riscos Técnicos
• De acordo com a probabilidade do evento
◦ Conhecidos
◦ Previsíveis
◦ Imprevisíveis
R.:
Comunicar
Identificar
Buscar e localizar os riscos antes que eles se tornem problemas reais
Analisar
Transformar os dados dos riscos em informações para tomada de decisão
Planejar
Traduzir e implementar as informações dos riscos em ações de decisão e
resolução de riscos
Monitorar
Monitorar indicadores dos riscos e seus planos de resolução
Controlar
Corrigir os desvios para os planos de resolução dos riscos
Um caminho é uma seqüência de vértices v1, v2, …, vn conectados por arestas (v1,
v2), (v2, v3), … (vn - 1, vn). As arestas são também consideradas como parte do
caminho. O comprimento de um caminho é dado pelo número de arcos que ele
contém.
Um circuito é um caminho onde o vértice final é igual ao inicial. Um circuito será
simples se nenhum vértice aparecer mais de uma vez, exceto o primeiro e o último.
Um circuito simples é chamado de ciclo. Um grafo sem ciclos é chamado de
acíclico.
Uma fonte é um vértice com grau de entrada 0 e grau de saída > 1. Um sumidouro é
um vértice com grau de saída 0 e grau de entrada > 1.
O programa make do Unix toma como entrada um arquivo texto contendo comandos
da forma
Nome : d1 d2 … dn
Comandos
ln é o linker e cc o compilador. Se, por exemplo, b.c for modificado, make irá
compilá-lo novamente (Comando "cc -c b.c"), porque ele será mais novo que
"b.obj". Então "b.obj" será mais novo que prog que será linkado por "ln -o
prog a.obj b.obj c.obj ".
As relações de dependências do make podem ser colocada em forma de um grafo.
void f(
{
if (i > 0)
{
j = 1;
goto L1;
a = 10;
}
else
j = 10;
return 1;
L1;
}
seria transformada no grafo
Para descobrir o código morto, fazemos uma busca a partir da primeira instrução do
procedimento marcando todos os vértices visitados. As instruções correspondentes
aos vértices não visitados nunca serão executados e podem ser removidos pelo
compilador.
Note que com este mesmo grafo pode-se descobrir se a instrução return será
executada por todos os caminhos que ligam o vértice inicial ao vértice "fim da
função". A resposta para o grafo acima é : não.
Exercícios