Análise de Sistemas Orientado a Objetos - 01

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?
• 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?
• 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.

• 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.

• 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

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.

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.

• 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ãofuncionais) 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.

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.

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).

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.

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.

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.

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.

Análise de Sistemas Orientado a Objetos - 01

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Análise de Sistemas Orientado a Objetos - 01

Mais de Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT

Análise de Sistemas Orientado a Objetos - 01