Análise de Sistemas

Orientada a Objetos
Aula 01 – Introdução à disciplina
O que veremos?
• Abordaremos conceitos aplicáveis sobre:
• Aspectos introdutórios.
• Sistema de Informação X Software.
• Papeis de membros de uma equipe de projeto software.
• Engenharia de Requisitos
• Requisitos: requisitos do usuário, requisitos do sistema, requisitos funcionais e requisitos
não-funcionais
• Técnicas para Coleta de Requisitos
• Documentação de Requisitos
• Gerenciamento de Requisitos
O que veremos?
• Abordaremos conceitos aplicáveis sobre:
• Modelagem de Processos de Negócio.
• Conceitos introdutórios sobre processos de negócio.
• Diagrama de Atividades.
• O papel do Analista de Negócio.
• Modelagem de Casos de Uso.
• Conceitos introdutórios sobre requisitos de software.
• Elicitação de Casos de Uso e Atores.
• Diagrama de Casos de Uso.
• Descrição de Casos de Uso.
• Estruturação do Diagrama de Casos de Uso.
• Requisitos não-funcionais .
O que veremos?
• Abordaremos conceitos aplicáveis sobre:
• Modelagem de Processos de Negócio.
• Conceitos introdutórios sobre processos de negócio.
• Diagrama de Atividades.
• O papel do Analista de Negócio.
• Modelagem de Casos de Uso.
• Conceitos introdutórios sobre requisitos de software.
• Elicitação de Casos de Uso e Atores.
• Diagrama de Casos de Uso.
• Descrição de Casos de Uso.
• Estruturação do Diagrama de Casos de Uso.
• Requisitos não-funcionais .
O que veremos?
• Abordaremos conceitos aplicáveis sobre:
• Análise OO com UML.
• Classes de Análise.
• Diagrama de Classes.
• Realização de Casos de Uso.
• Colaborações.
• Diagrama de Sequência.
• Diagrama de Colaboração (Comunicação).
• Diagrama de Máquina de Estados.
• Estruturação de sistemas em subsistemas e camadas.
• Diagrama de Pacotes.
• Acoplamento X Coesão.
Bibliografia
• BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - guia do usuário. 2. ed. Rio de
Janeiro, Campus, 2006.
• BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML: um guia prático
para modelagem de sistemas orientados a objetos através da linguagem de
modelagem unificada. Rio de Janeiro, Campus.
• LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto
orientados a objetos e ao processo unificado. 2. Ed. Porto Alegre. Bookman. 2004.

Bibliografia Complementar
• PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
• SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007.
Frequência em sala de aula
• Cada noite de aula correspondem a 3 (três) presenças
• Exigência mínima de presença em sala de aula para aprovação: 75%
Avaliação
● Padrão UNIP: NP1 e NP2
● Avaliações com questões de múltipla escolha e
dissertativas, totalizando 10 questões por avaliação.
● Média Semestral (MS) deverá ser igual ou superior a 5,0 para
aprovação

MS = ((NP1 x 4) + (PIM x 2) + (NP2 x 4)) / 10

Aspectos Introdutórios
• Sistema de Informação:
• Conjunto de componentes inter-relacionados trabalhando juntos para coletar,
recuperar, processar, armazenar e distribuir informações com a finalidade de
facilitar o planejamento, o controle, a coordenação, a análise e o processo
decisório em empresas e outras organizações [Laudon].

• Gera informações utilizáveis para a coordenação de fluxo operacional de

trabalho de uma empresa, bem como suporte à tomada de decisões. Um
sistema de informação pode ser totalmente manual ou ser automatizado.
Aspectos Introdutórios
• Elementos de um Sistema de Informação:
• Organizações: Empresas são organizações formais. Subdivide-se em
unidades organizacionais (UO) hierárquicas e estruturadas. Cada UO possui
processos e regras de negócio que são executados por pessoas e/ou
software.
• Pessoal: Colaboradores da empresa que executam processos de negócio e
operam computadores. São consumidores e geradores de informações.
• Procedimentos: É um conjunto de tarefas que podem ser manuais ou
automatizadas por algum software, ou ainda que poderão ser
automatizadas por um software a ser desenvolvida em uma ocasião
futura.
Aspectos Introdutórios
• Elementos de um Sistema de Informação:
• Software: Artefato de código que tem por objetivo a execução de um conjunto de
instruções que automatizam um processo ou um trecho de um processo de
negócio.
• Hardware: Dispositivos eletrônicos que fornecem capacidade computacional,
dispositivos de interconectividade, dispositivos eletromecânicos. O hardware é
um meio eletrônico que permite a execução de um artefato de software.
• Base de dados: Como o próprio nome sugere, é um conjunto de dados que são
atualizados pelo software. Essas atualizações são feitas através de procedimentos
de inclusão, alteração, exclusão e consulta de entidades de negócio.
• Documentação: Informação descritiva que mostra o uso e/ou operação do
sistema. Podem ser normas, padrões, regras, políticas, descritivos de
procedimentos, sistemáticas e processos relativos ao negócio foco do sistema de
informação em questão.
Cenário atual do desenvolvimento de software
Cenário atual do desenvolvimento de software
Causas de falhas em projetos de software
Requisitos e análise de sistemas
Requisitos - Definição
Segundo o Rational Unified Process (RUP):
É uma condição ou uma capacidade que deve ser atendida pelo sistema.

Definição do IEEE (Institute of Electrical and Electronics Engineers):

É uma condição ou capacidade que deve ser atendida pelo software, necessária a
um usuário para solucionar um problema ou atender a um objetivo.
O conjunto de todos os requisitos formam a base para posterior desenvolvimento
do sistema ou componente do sistema.

SWEBOK (Software Engineer Body Of Knowledge)

Expressa necessidades e restrições ao produto de software que contribui para a
solução de problemas no domínio do negócio.
Engenharia de Requisitos
É 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.
O processo de engenharia de requisitos é composto por quatro
atividades de alto nível :
• identificação;
• análise e negociação;
• especificação e documentação;
• validação.
Engenharia de Requisitos
Engenharia de Requisitos
Engenharia de Requisitos
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.
Engenharia de Requisitos
• 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 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?
Engenharia de Requisitos - identificação
• Algumas das atividades envolvidas nesta fase incluem:
• Compreensão do domínio: é muito importante para o analista compreender o
domínio no qual a organização e o projeto se inserem; quanto maior for o
conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista
e as partes interessadas.
• Identificação das partes interessadas: estes já deverão ter sido identificados nos
estudos de viabilidade, porém para efeitos de identificação de requisitos convém
concentrar as atenções nos usuários do sistema.
• Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-
funcionais) pretendidos para o sistema.
• Identificação e análise de problemas: os problemas devem ser identificados (e a
sua definição deve ser consensual) e devem ser propostas soluções em conjunto
com as partes interessadas.
Engenharia de Requisitos - identificação
Algumas dificuldades típicas estão associadas:
• O cliente pode não saber exatamente o que deseja para o sistema, ou
sabê-lo mas não conseguir articulá-lo (o que é bastante comum).
• Os requisitos identificados podem não ser realistas (do ponto de vista
econômico ou tecnológico, por exemplo).
• Cada parte interessada pode expressar os mesmos requisitos de
formas diferentes, sendo necessário - através de um bom
conhecimento do domínio - identificar estas situações.
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Entrevistas e Questionários
• É a técnica mais simples de utilizar. Está condicionada a alguns fatores:
• Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê
margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.
• Relação pessoal entre os intervenientes na entrevista.
• Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a
ser afetado pela introdução de um sistema na organização, este pode
propositadamente dificultar o acesso à informação.
• Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é
natural que haja tendência para que os intervenientes se dispersem um pouco,
levando a que a entrevista demore mais tempo do que seria suposto. Caso a
entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer
despachar" sendo os últimos pontos da entrevista abordados de forma superficial
(ou podem nem chegar a ser abordados).
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Workshops de requisitos
• Consiste numa técnica usada através de uma reunião estruturada, da qual
devem fazer parte um grupo de analistas e um grupo representando o
cliente , para então obter um conjunto de requisitos bem definidos.
• Ao contrário das reuniões, promove-se a interação entre todos os elementos
presentes no workshop fomentando momentos de descontração como forma
de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel
é conduzir o workshop e promover a discussão entre os vários intervenientes.
• As tomadas de decisão devem seguir processos bem definidos e devem
resultar de um processo de negociação, mediado pelo facilitador. Uma técnica
que é também útil em workshops é o uso de brainstorming como forma de
gerar um elevado número de ideias numa pequena quantidade de tempo.
• Como resultado dos workshops deve ser produzida documentação que reflita
os requisitos e decisões tomadas sobre o sistema a implementar.
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Cenários
• Uma forma de levar as pessoas a imaginarem o comportamento de um
sistema. Através de exemplos práticos descritivos do comportamento de
um sistema, os seus usuários podem comentar acerca do seu
comportamento e da interação que esperam ter com ele. Trata-se de
uma abordagem informal, prática e aplicável a qualquer tipo de sistema.
De um modo geral, os cenários devem incluir os seguintes elementos:
• estado do sistema no início do cenário;
• sequência de eventos esperada (na ausência de erros) no cenário;
• listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de
como estes erros serão tratados;
• outras atividades que podem ser executadas ao mesmo tempo que as deste
cenário;
• estado do sistema depois de o cenário terminar.
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Prototipagem
• Versão inicial do sistema, baseada em requisitos ainda pouco definidos,
mas que pode ajudar a encontrar desde cedo falhas que através da
comunicação verbal não são tão facilmente identificáveis.
• São desenvolvidas apenas algumas funcionalidades sendo normalmente
desenvolvidas primeiro aquelas que são mais fáceis de compreender
por parte do utilizador e que lhe podem trazer maior valor
acrescentado.
• O uso de protótipos deve ser considerado apenas mediante uma análise
custo-benefício, já que os custos de desenvolvimento de um protótipo
podem facilmente crescer, sendo particularmente úteis em situações
em que a interface com os usuários é, para eles, um aspecto crítico.
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Estudo etnográfico
• Análise de componente social das tarefas desempenhadas numa dada
organização.
• Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é
de se 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.