1) Leia o Capítulo 1, Enquadramento, do livro adotado e resposta às seguintes

questões.

1.1) Explique, com base na definição de Anthony, a diferença entre um sistema de

informação operacional, táctico e estratégico. Dê exemplos para clarificar a sua
justificação.

Michael J. Anthony propôs uma definição de sistemas de informação em 1965

[Anthony65] que inclui três níveis: operacional, tático e estratégico.

Sistema de Informação Operacional (SIO):

Nível operacional responsável pelo processamento diário das transações e atividades

do dia-a-dia numa organização.
Um exemplo é um sistema de ponto de venda num supermercado com o registo de vendas
de produtos, controlo de stock em tempo real, criação de relatórios

Sistema de Informação Tático (SIT):

Este nível está relacionado ao apoio às atividades de gestão a curto prazo para a
tomada de decisões relacionadas ao planeamento e controlo.
Um exemplo de sistemas de apoio à decisão tática, tais sistemas business
intelligence, será por exemplo um sistema que analisa os dados de vendas mensais e
trimestrais para identificar tendências de mercado e auxiliar os gestores na
definição de estratégias de estabelecimento dos preços.

Sistema de Informação Estratégico (SIE):

Este nível está direccionado para o apoio à gestão de topo na formulação de

estratégias de médio e longo prazo, na tomada de decisões que ajudam a
administração nos objetivos da organização como um todo.

Em sistemas de apoio à decisão estratégica, sistemas de planeamento empresarial

teremos como exemplo, um sistema que agrega dados sobre concorrentes, tendências de
mercado e mudanças regulatórias para a gestão de de topo poder tomar decisões sobre
a expansão para novos mercados, a introdução de novos produtos, preços.
Em resumo, a diferença entre os sistemas de informação operacional, tático e
estratégico reside principalmente no nível de agregação dos dados, das informações
fornecidas e decisões no horizonte de tempo e do público-alvo.

1.2) Enumere os três principais problemas relacionados com o desenvolvimento de

sistemas de informação. Enumere três das causas conhecidas.

A falta de qualidade, o desvio dos prazos e custos previamente definidos são três
das causas enumeradas, existem também outros problemas comuns no desenvolvimento de
sistemas de informação frequentes tais como ambientes em constante mudança, muitos
projetos de desenvolvimento de sistemas sofrem com ambientes de informação com
objectivos mal definidos ou em constante mudança. Resulta em requisitos mal
compreendidos ou incompletos, levando a refazer o trabalho, atrasos e custos
adicionais. A falta de uma definição clara dos objectivos a traçar pode levar a
falsas expectativas.

A Comunicação inadequada: Uma comunicação eficaz é essencial para o sucesso de um

projeto de desenvolvimento de sistemas de informação. Problemas de comunicação
entre os membros da equipa, as partes interessadas e utilizadores finais podem
levar a mal-entendidos, conflitos e decisões erradas. Falhas na comunicação
resultam em requisitos mal interpretados, alterações não comunicadas ou feedback
insuficiente, prejudicando a qualidade e a entrega do projeto.
Por último e nos tempso que correm teremos os riscos de segurança e privacidade:
Com a crescente quantidade de dados pessoais e confidenciais armazenados e
processados por sistemas de informação, os riscos de segurança cibernética e
violações de privacidade são cada vez mais preocupantes. A falta de medidas
adequadas de segurança e conformidade com os regulamentos pode expor os sistemas a
ameaças externas, como ataques de hackers, malware ou phishing, bem como a
violações de privacidade que resultam em danos à reputação e responsabilidade
legal. Garantir a segurança e a privacidade dos dados deve ser uma prioridade em
todos os estágios do desenvolvimento do sistema.

2) Leia o Capítulo 2, Desenvolvimento de Software, do livro adotado e resposta às

seguintes questões.

2.1) Quais as fases e respetivas tarefas no processo de desenvolvimento de

software? Explique cada tarefa.

Tradicionalmente como indicado no livro o processo de desenvolvimento de software é

frequentemente dividido em fases que incluem concepção (ou análise), implementação
e manutenção. De forma simplista será projectar a solução, codificar a solução e
por último os testes, abaixo detalha-se cada fase e as respectivas tarefas:

Concepção (ou análise):

Levantamento de requisitos: Esta fase envolve a identificação e documentação dos
requisitos do sistema, ou seja, as funcionalidades e características que o software
deve ter para atingir as necessidades dos utilizadores e da organização.
Análise de requisitos: O levantamento dos requisitos são analisados e orientados
para garantir que sejam claros, completos e consistentes. Envolve a colaboração com
os utilizadores finais e as partes interessadas para garantir que as suas
necessidades sejam compreendidas e consideradas.
Especificação de requisitos: Os requisitos são formalmente documentados numa
especificação de requisitos que vai servir como base para o design e implementação
do sistema. Isso inclui os detalhes sobre os requisitos funcionais e não
funcionais, assim como casos de utilização ou os seus cenários.

Implementação:
Design do sistema: Com base nos requisitos especificados, é elaborado um design
detalhado do sistema, incluindo a arquitetura de software, estrutura de dados,
interfaces de utilizador e outros elementos importantes.
Codificação: Nesta fase, é escrito o código fonte do software com base no design
estabelecido. Isso envolve a tradução dos requisitos e especificações num código
executável usando uma ou mais linguagens de programação.
Testes unitários: À medida que o código é desenvolvido, são realizados testes
unitários para verificar a correção do código ao nível do componente ou módulo.
Isso ajuda a identificar e corrigir erros de programação antes que se tornem em
maiores problemas em todo o sistema.

Manutenção:
Testes de integração: Após a implementação de todos os componentes do sistema, são
realizados testes de integração para verificar os diferentes módulos, se funcionam
corretamente juntos e se o sistema atende aos requisitos especificados. O software
é implementado no ambiente de produção, pronto para ser utilizado pelos
utilizadores finais, pode envolver a instalação do software em servidores, a
configuração de sistemas e a migração de dados, dependendo da complexidade do
sistema.
Em termos de manutenção corretiva e evolutiva ou preditiva: Após o lançamento, o
software pode precisar de correções de bugs, melhorias de desempenho ou novas
funcionalidades. A fase de manutenção inclui atividades para corrigir problemas
identificados pelos utilizadores, bem como para evoluir o software para suprir as
necessidades em constante mudança da organização e dos utilizadores.
Estas fases e tarefas comuns no processo de desenvolvimento de software podem
variar dependendo da metodologia de desenvolvimento utilizada e das características
específicas do projeto.

2.2) Na sequência das críticas apontadas ao ciclo de vida em cascata, foi sugerida
a aplicação de técnicas de prototipagem como forma de ultrapassar esses problemas,
o que resultou num novo ciclo de desenvolvimento. Concorda que, apenas por este
facto, se possa considerar um novo ciclo? Justifique.

As críticas apontadas ao ciclo de vida em cascata (planeamento, análise, desenho,

desenvolvimento, testes, manutenção pode resultar num novo ciclo de desenvolvimento
?.

É requerida uma resposta ambígua à questão:

A introdução de técnicas de prototipagem como uma forma de ultrapassar as

limitações do ciclo de vida em cascata pode certamente resultar numa abordagem de
desenvolvimento diferente, mas não necessariamente em um novo ciclo de
desenvolvimento por si só.

Como se referiu, o ciclo de vida em cascata é caracterizado por uma sequência

linear de fases, onde cada fase é concluída antes de passar para a próxima e que
pode levar a problemas como requisitos mal compreendidos ou mudanças de requisitos
no final do ciclo, que são descobertos muito tarde no processo.

De facto a introdução de prototipagem pode ajudar a mitigar esses problemas,

permitindo que os utilizadores vejam e testem partes do sistema antes que estejam
completamente desenvolvidas e que vai ajudar a validar os requisitos e identificar
mudanças necessárias mais cedo no processo, evitando efectuar novamente o trabalho
com os custos adicionais inerentes.

No entanto, adicionar simplesmente a prototipagem ao ciclo de vida em cascata não

constitui necessariamente um novo ciclo de desenvolvimento. Será mais uma
modificação ou melhoria na abordagem de desenvolvimento dentro do mesmo ciclo de
vida em cascata. Será um ciclo de vida em cascata modificado, agora incorporando
prototipagem, pode ser considerado uma iteração do ciclo original, em vez de um
ciclo completamente novo.

Portanto em jeito de conclusão, enquanto a introdução de prototipagem pode

representar uma mudança significativa na abordagem de desenvolvimento, não é
suficiente para caracterizar um novo ciclo de desenvolvimento por si só.

3) Leia os slides em anexo sobre Análise de Requisitos

3.1) Exemplifique requisitos funcionais e não funcionais.

Funcionais: O sistema deve permitir a inclusão, alteração e remoção de

funcionários com os seguintes atributos: nome, endereço,
cidade,etc).
O utilizador deve ser capaz de pesquisar todo o conjunto inicial do BD ou
selecionar um subconjunto a partir dele.
O sistema fornecerá ecrãs apropriados para o utilizador ler documentos
Cada pedido tem um único identificador.

Requisitos Não Funcionais

Organizacionais: refere-se a políticas e procedimentos nas organizações do cliente
e de quem desenvolve.
- de entrega, de implementação, padrões de processo
Externos: refere-se a fatores externos ao sistema e ao seu processo de
desenvolvimento.
- interoperabilidade (interação do sistema com outros), éticos, legais (privacidade
e de segurança)
De produto: especificam o comportamento do produto.
- (desempenho, espaço, rapidez, memória),confiabilidade, portabilidade.

3.2) Quais as formas mais usuais de levantamentos dos requisitos?

3.1) Exemplifique requisitos funcionais e não funcionais. São declarações de

funções de como o sistema deve reagir a entradas específicas e como deve comportar
em determinadas situações. É uma interação entre o sistema e o seu ambiente.
Algumas vezes, os requisitos funcionais podem também explicitamente declarar o que
o sistema não deve fazer. A especificação deve ser completa e consistente.

Funcionais: O sistema deve permitir a inclusão, alteração e remoção de funcionários

com os seguintes atributos: nome, endereço, cidade,etc). O utilizador deve ser
capaz de pesquisar todo o conjunto inicial do BD ou selecionar um subconjunto a
partir dele. O sistema fornecerá ecrãs apropriados para o utilizador ler
documentos. Cada pedido tem um único identificador.

- Documentação: Essa documentação deve ser online, no formato de livro, ou ambos?

- Dados: Qual será o fluxo de dados do sistema?
- Segurança: O acesso ao sistema ou às informações deve ser controlado?
- Recursos: Quanto espaço físico será ocupado pelo sistema ?