SlideShare une entreprise Scribd logo
1  sur  28
Télécharger pour lire hors ligne
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ã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.
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.

Contenu connexe

Tendances

Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Rosanete Grassiani dos Santos
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitoselliando dias
 
Análise de sistemas análise de requisitos
Análise de sistemas   análise de requisitosAnálise de sistemas   análise de requisitos
Análise de sistemas análise de requisitosMá Puia
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosNorton Guimarães
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Especificação requisitos
Especificação requisitosEspecificação requisitos
Especificação requisitosLuis Fernandes
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de SoftwareRalph Rassweiler
 
Práticas de Desenvolvimento de Software
Práticas de Desenvolvimento de SoftwarePráticas de Desenvolvimento de Software
Práticas de Desenvolvimento de SoftwareTiago Barros
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitoselliando dias
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitosTamires Guedes
 
Fundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de RequisitosFundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de RequisitosBarbara Lima
 
Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Tiago Barros
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Luís Fernando Richter
 

Tendances (20)

Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Analise sistemas 04
Analise sistemas 04Analise sistemas 04
Analise sistemas 04
 
Análise de sistemas análise de requisitos
Análise de sistemas   análise de requisitosAnálise de sistemas   análise de requisitos
Análise de sistemas análise de requisitos
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de Requisitos
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Especificação requisitos
Especificação requisitosEspecificação requisitos
Especificação requisitos
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Analise sistemas 03
Analise sistemas 03Analise sistemas 03
Analise sistemas 03
 
Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04
 
Práticas de Desenvolvimento de Software
Práticas de Desenvolvimento de SoftwarePráticas de Desenvolvimento de Software
Práticas de Desenvolvimento de Software
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
 
Aula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de RequisitosAula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de Requisitos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Fundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de RequisitosFundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de Requisitos
 
Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 

En vedette

Análise Orientada a Objetos - Objetos E Classes
Análise Orientada a Objetos  -   Objetos E ClassesAnálise Orientada a Objetos  -   Objetos E Classes
Análise Orientada a Objetos - Objetos E ClassesCursoSENAC
 
Contraccion muscular histologia
Contraccion muscular histologiaContraccion muscular histologia
Contraccion muscular histologiaSheyLaa Torres
 
Metodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informaçãoMetodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informaçãoJean Carlos
 
O paradigma da orientação a objetos
O paradigma da orientação a objetosO paradigma da orientação a objetos
O paradigma da orientação a objetosNécio de Lima Veras
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projetoejdn1
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de SistemasGuilherme
 
Metodologia orientado a objetos
Metodologia orientado a objetosMetodologia orientado a objetos
Metodologia orientado a objetosGabriel Faustino
 

En vedette (8)

Análise Orientada a Objetos - Objetos E Classes
Análise Orientada a Objetos  -   Objetos E ClassesAnálise Orientada a Objetos  -   Objetos E Classes
Análise Orientada a Objetos - Objetos E Classes
 
Contraccion muscular histologia
Contraccion muscular histologiaContraccion muscular histologia
Contraccion muscular histologia
 
Metodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informaçãoMetodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informação
 
O paradigma da orientação a objetos
O paradigma da orientação a objetosO paradigma da orientação a objetos
O paradigma da orientação a objetos
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projeto
 
Paradigmas de programação
Paradigmas de programaçãoParadigmas de programação
Paradigmas de programação
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Metodologia orientado a objetos
Metodologia orientado a objetosMetodologia orientado a objetos
Metodologia orientado a objetos
 

Similaire à Análise de Sistemas Orientado a Objetos - 01

Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducaolicardino
 
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdfPedro Alcantara
 
A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...André Agostinho
 
Modelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfModelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfIvanFontainha
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosJosé Vieira
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de SoftwareRobson Silva Espig
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixCris Fidelix
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de softwareFelipe Bugov
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemasPriscila Stuani
 
Conceito de analise de desenvolvivento de sistemas
Conceito de analise de desenvolvivento de sistemasConceito de analise de desenvolvivento de sistemas
Conceito de analise de desenvolvivento de sistemasluanrjesus
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitosFelipe Oliveira
 
Analise de requisitos estudo para prova
Analise de requisitos estudo para provaAnalise de requisitos estudo para prova
Analise de requisitos estudo para provaLeonardo Almeida
 
57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdf57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdfRicardoZorekDaniel1
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosGustavo Lopes
 
Técnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter CybisTécnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter CybisLuiz Agner
 
Engenharia de software i 3 - processos de engenharia de requisitos
Engenharia de software i   3 - processos de engenharia de requisitosEngenharia de software i   3 - processos de engenharia de requisitos
Engenharia de software i 3 - processos de engenharia de requisitosWillian Moreira Figueiredo de Souza
 

Similaire à Análise de Sistemas Orientado a Objetos - 01 (20)

Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducao
 
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf
2. FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO - 22.06.22.pdf
 
Análise de requisitos
Análise de requisitosAnálise de requisitos
Análise de requisitos
 
A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...
 
Modelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfModelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdf
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
 
AMSI.pptx
AMSI.pptxAMSI.pptx
AMSI.pptx
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
 
Conceito de analise de desenvolvivento de sistemas
Conceito de analise de desenvolvivento de sistemasConceito de analise de desenvolvivento de sistemas
Conceito de analise de desenvolvivento de sistemas
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
 
Processo e Processo de Software
Processo e Processo de SoftwareProcesso e Processo de Software
Processo e Processo de Software
 
Analise de requisitos estudo para prova
Analise de requisitos estudo para provaAnalise de requisitos estudo para prova
Analise de requisitos estudo para prova
 
57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdf57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdf
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
 
Técnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter CybisTécnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter Cybis
 
Engenharia de software i 3 - processos de engenharia de requisitos
Engenharia de software i   3 - processos de engenharia de requisitosEngenharia de software i   3 - processos de engenharia de requisitos
Engenharia de software i 3 - processos de engenharia de requisitos
 

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

Plus de Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT (20)

Curso DNA Básico Thetahealing
Curso DNA Básico ThetahealingCurso DNA Básico Thetahealing
Curso DNA Básico Thetahealing
 
Atendimento ThetaHealing
Atendimento ThetaHealingAtendimento ThetaHealing
Atendimento ThetaHealing
 
Modelagem de Sistemas de Informação 13 maquina_estados
Modelagem de Sistemas de Informação 13 maquina_estadosModelagem de Sistemas de Informação 13 maquina_estados
Modelagem de Sistemas de Informação 13 maquina_estados
 
Análise de Sistemas Orientado a Objetos - 11 - maquina_estados
Análise de Sistemas Orientado a Objetos - 11 - maquina_estadosAnálise de Sistemas Orientado a Objetos - 11 - maquina_estados
Análise de Sistemas Orientado a Objetos - 11 - maquina_estados
 
Modelagem de Sistemas de Informação 12 pacotes
Modelagem de Sistemas de Informação 12 pacotesModelagem de Sistemas de Informação 12 pacotes
Modelagem de Sistemas de Informação 12 pacotes
 
Análise de Sistemas Orientado a Objetos - 10 - pacotes
Análise de Sistemas Orientado a Objetos -  10 - pacotesAnálise de Sistemas Orientado a Objetos -  10 - pacotes
Análise de Sistemas Orientado a Objetos - 10 - pacotes
 
Modelagem de Sistemas de Informação 11 Colaboração
Modelagem de Sistemas de Informação 11 ColaboraçãoModelagem de Sistemas de Informação 11 Colaboração
Modelagem de Sistemas de Informação 11 Colaboração
 
Análise de Sistemas Orientado a Objetos - 09 - colaboracao
Análise de Sistemas Orientado a Objetos - 09 - colaboracaoAnálise de Sistemas Orientado a Objetos - 09 - colaboracao
Análise de Sistemas Orientado a Objetos - 09 - colaboracao
 
Modelagem de Sistemas de Informação 10 Diagrama de Sequência
Modelagem de Sistemas de Informação 10 Diagrama de SequênciaModelagem de Sistemas de Informação 10 Diagrama de Sequência
Modelagem de Sistemas de Informação 10 Diagrama de Sequência
 
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de SequênciaAnálise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
 
Análise de Sistemas Orientado a Objetos - 07 ISO 9126
Análise de Sistemas Orientado a Objetos - 07 ISO 9126Análise de Sistemas Orientado a Objetos - 07 ISO 9126
Análise de Sistemas Orientado a Objetos - 07 ISO 9126
 
Modelagem de Sistemas de Informação 09 ISO 9126
Modelagem de Sistemas de Informação 09 ISO 9126Modelagem de Sistemas de Informação 09 ISO 9126
Modelagem de Sistemas de Informação 09 ISO 9126
 
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de ClassesModelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
 
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de ClassesAnálise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
 
Modelagem de Sistemas de Informação 06
Modelagem de Sistemas de Informação 06Modelagem de Sistemas de Informação 06
Modelagem de Sistemas de Informação 06
 
Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05
 
Modelagem de Sistemas de Informação 03
Modelagem de Sistemas de Informação 03Modelagem de Sistemas de Informação 03
Modelagem de Sistemas de Informação 03
 
Modelagem de Sistema de Informação 02
Modelagem de Sistema de Informação 02Modelagem de Sistema de Informação 02
Modelagem de Sistema de Informação 02
 
Modelagem de Sistemas de Informação 01
Modelagem de Sistemas de Informação 01Modelagem de Sistemas de Informação 01
Modelagem de Sistemas de Informação 01
 
Análise de Sistemas Orientado a Objetos - 04
Análise de Sistemas Orientado a Objetos - 04Análise de Sistemas Orientado a Objetos - 04
Análise de Sistemas Orientado a Objetos - 04
 

Análise de Sistemas Orientado a Objetos - 01

  • 1. Análise de Sistemas Orientada a Objetos Aula 01 – Introdução à disciplina
  • 2. 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
  • 3. 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 .
  • 4. 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 .
  • 5. 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.
  • 6. 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.
  • 7. 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%
  • 8. 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
  • 9. 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.
  • 10. 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.
  • 11. 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.
  • 12. Cenário atual do desenvolvimento de software
  • 13. Cenário atual do desenvolvimento de software
  • 14. Causas de falhas em projetos de software
  • 15. Requisitos e análise de sistemas
  • 16. 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.
  • 17. 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.
  • 20. 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.
  • 21. 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?
  • 22. 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.
  • 23. 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.
  • 24. 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).
  • 25. 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.
  • 26. 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.
  • 27. 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.
  • 28. 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.