Upload
diiogoamaral
View
14
Download
0
Embed Size (px)
DESCRIPTION
Material de Estudo Engenharia de Software
Citation preview
28-04-2023 HAIDER NOOR 2
NOTAS Exame escrito
28-04-2023 HAIDER NOOR 3
PLANO CURRICULAR CAP I – Introdução a engenharia de software CAP II – Gestão de projectos CAP III – Processos de Software CAP IV – Metodologias ágeis de desenvolvimento CAP V – Engenharia de Requisitos CAP VI – Projecto ou desenho de software CAP VII – Implementação ou Desenvolvimento CAP VIII – Verificação e validação CAP IX – entrega e manutenção
28-04-2023 HAIDER NOOR 4
AVALIAÇÕES Semana 4, aula 7 – PR1 - 150pts – gestão de projectos Apresentação
2 documentos Ficha de projecto (
Capa 1 pág Missão e âmbito Restrições Pressupostos Objectivos riscos conhecidos Custos associados Marcos do Projecto
Plano do projecto Detalhe das sub-actividades em cada marco e o
responsável, diagrama de Gant,
1 pág
Marco dependência Data de início Data de fim
No âmbito do nosso trabalho, o quê que nós não vamos fazer e porquê?
28-04-2023 HAIDER NOOR 5
AVALIAÇÕES 7 semana, aula 16 – MT – 70pts - Gestão de projectos, processos de software e metodologias ágeis.
9 semana, aula 23 – T1- 100pts – tudo do Mt + eng. de Requisitos. 10 semana, aula 25 – PR2 – 100pts – Eng d Requisitos. 12 semana, aula 32 – PR3 – 100pts – projecto ou desenho de sofware
15 semana, aula 42 – T2 – 100pts – projecto ou desenho de software, verificação e validação, entrega e manutenção.
16 semana, aula 44 – PR4 – 150pts – implementação, verificação e validação. Entrega.
28-04-2023 HAIDER NOOR 6
CAP – I: INTRODUÇÃO A ENGENHARIA DE
SOFTWARE
28-04-2023 HAIDER NOOR 7
INTRODUÇÃO A ENGENHARIA DE SOFTWARE Software: são programas/instruções que realizam tarefas específicas. Conjunto de instruções codificadas numa linguagem de programação. Definição do stor -> Um conjunto de programas e a sua documentação associada.
Desenvolvimento de software: é todo o processo de elaborar e implementar um produto de software.
Engenharia de software: a área da engenharia que se relaciona com todos os aspectos de produção de um software.
28-04-2023 HAIDER NOOR 8
MITOS DOS SOFTWARES Mito 1 – o facto de uma equipa ter a sua disposição manuais repletos de padrões e procedimentos de desenvolvimento implica que a equipa está apta a bem encaminhar o desenvolvimento.
Mito 2 – o facto de possuir o melhor computador é a melhor ferramenta de desenvolvimento de software.
Mito 3 – Mais pessoas melhora o tempo de desenvolvimento. Mito 4 – uma discrição geral daquilo que é o problema é suficiente para iniciar o projecto. (projecto é uma fase do desenvolvimento/concepção)
Mito 5 – o facto do desenvolvimento de software ser flexível implica que podemos aumentar requisitos a qualquer momento.
Mito 6 – após a produção e implementação do software o trabalho está terminado. Mito 7 – no final do projecto, o produto a entregar é o programa em funcionamento. Mito 8 – o processo de planeamento fara com que criemos documentação volumosa que atrasara a execução do projecto e assim atrasara o cronograma,
28-04-2023 HAIDER NOOR 9
CAP II – GESTÃO DE PROJECTOS DE
SOFTWARE
28-04-2023 HAIDER NOOR 10
GESTÃO DE PROJECTOS DE SOFTWARE Gestão – Objectivo: minimizar os custos e tempo de desenvolvimento.
Para se estabelecer quanto tempo o nosso projecto vai levar, há que ter em conta 2 factores: O produto Os recursos (pessoal)
28-04-2023 HAIDER NOOR 11
PRODUTO (EXEMPLO)Especificação
• Engenharia do sistema
• Engenharia de requisitos
• Especificação do sistema
Desenho
• Desenho da arquitectura
• Desenho das interfaces
• Desenho detalhado
Implementação
• codificação
Verificação e validação
• Testes unitários
• Testes de integração
Um software é o produto final. As fases de desenvolvimento do software:
28-04-2023 HAIDER NOOR 12
RECURSOS (EXEMPLO) Os recursos mais difíceis de manegar são as pessoas. Um projecto tem, geralmente: Gestor de projecto Desenvolvedor Analista de projecto
Cada papel deve ser desempenhado pela pessoa certa. Aspectos como liderança, coordenação, relação com outros, etc.
28-04-2023 HAIDER NOOR 13
FORMAÇÃO DE EQUIPAS O tamanho da equipa tem muita influença sobre a eficácia da equipa. Equipas grandes requerem maior esforço de gestão.
É melhor formar muitas equipas pequenas do que poucas equipas grandes.
Tipos(como é gerida) de equipa mais utilizados: Democrática descentralizada Controlada descentralizada Controlada centralizada
28-04-2023 HAIDER NOOR 14
Democrática descentralizada
O projecto é divido em M tarefas que é entregue a N indivíduos e as suas equipas. E a gestão é feita pelo gestor de projecto.
Controlada descentralizada (a melhor forma de formar equipas)
Leva-se um projeto como um todo e divide-se em subprocessos que são atribuídos a sub-gestores que tem autonomia sobre a gestão dos mesmos. (Delegação)
Controlada centralizada
O gestor de projecto é responsável por gerir todas as equipas e as suas interações.
28-04-2023 HAIDER NOOR 15
ESTIMATIVAS Trazem valores aproximados a aquilo que é a realidade do projecto. Técnicas para estabelecer estimativas:1. Postergar as estimativas para o mais tarde no projecto;
Inconveniente -> a maior parte dos clientes precisa ter uma previsão de gastos e tempos no principio do projecto
2. Estimativas baseadas em métodos não algorítmicos;a) estimativas usando projectos similares; (inconveniente – inexistência de projectos similares)b)estimativas na base de opinião de um perito (especialista); (inconveniente – inexistência de um
especialista)c) estimativa na base de melhor preço.
Assume-se que o contracto vai ser sempre respeitado pelo cliente (inconveniente – não há garantia de qualidade de software, preço pode ser sobre ou sub
estimado )3. Estimativa baseadas em métodos algorítmicos (empíricos)
28-04-2023 HAIDER NOOR 16
O QUÊ QUE NÓS ESTIMAMOS? 1. Tempo2. Custo3. Tamanho4. Esforço Primeiramente, é necessário estimar-se o tamanho o projecto em LOC (Lines of Code). O inconvenientes: É que é complicado contar linhas de código no inicio do projecto É complicado estimar linhas de código quando se usam várias linguagens de programação.
Para resolver estes problemas, contam-se pontos de função e depois, com ajuda de uma tabela, converte-se em LOC.
28-04-2023 HAIDER NOOR 17
TABELA DE CONVERSÃO PF - LOC Linguagem LOC/PFC 162C++ 66Java 63SQL 40
28-04-2023 HAIDER NOOR 18
ESFORÇO Esforço é o tempo que um determinado recurso disponibiliza para um determinado trabalho. Para tal devemos de tomar em consideração: Experiência dos trabalhadores;
TEMPOTempo total de desenvolvimento do projecto. Dependente do tamanho e do esforço. Usando opiniões de especialistas ou tempos de projectos similares.
28-04-2023 HAIDER NOOR 19
CUSTO Custos a considerar são: Custo de aquisição de equipamento; Custo de aquisição de software de suporte; Custos de esforço humano. (equipa de desenvolvimento) Custos gerais (energia, internet, transporte, etc.. )
28-04-2023 HAIDER NOOR 20
GESTÃO DE RISCORisco – é um evento que, caso ocorra, influenciará negativamente no desenvolvimento do projecto. Tipos de risco: Risco de projecto;
Modificação do cronograma; Risco de negócio;
Concorrência; Cliente muda de ideias;
Risco de produto; O produto não corresponde as necessidades do cliente; Compra de componentes defeituosos; falhas de desenvolvimento;
28-04-2023 HAIDER NOOR 21
TAREFAS DE GESTÃO DE RISCOS São as diferentes actividade que tem que ser executadas para evitar que o risco ocorra.
Divide-se em: Avaliação do risco;
O que causou? Qual é a probabilidade de ocorrência? Qual o seu impacto no projecto? É necessário de estabelecer níveis de referencia de custos, tempo e produtividade.
Administração de riscos; Efectuar acções que ajudem a mitigar o risco: redução do impacto e redução de probabilidade de
ocorrência. Nem todos riscos do projecto devem ser geridos. Devem ser gerir os riscos de média a alta
probabilidade de ocorrência e impacto no projecto.
Impacto
Probabilidade de ocorrência
28-04-2023 HAIDER NOOR 22
CRONOGRAMA Diagrama de Gantt Limitação – da o tempo de término mais cedo possível.
Diagrama de Pert Fornece o tempo mais cedo e mais tarde possível.
Tarefa critica é aquela que não pode atrasar. Se esta atrasar o projecto inteiro atrasa.
28-04-2023 HAIDER NOOR 23
DIAGRAMA DE GANTT
28-04-2023 HAIDER NOOR 24
Referência
tarefa dependência duração
A Por farinha no recipiente 3B Por dois ovos A 30C Por leite e misturar B 60D Escolher aromas 3E Cortar bananas em laminas
finas30
F Misturar as bananas com aromas
D,E 3
G Aquecer e misturar F 120H Por a mistura num ferro
quenteG 10
I Deixar a panqueca cozer C 10J Despejar a mistura na
panquecaI,H 10
k comer j 120
28-04-2023 HAIDER NOOR 25
Desenhar a rede de tarefar e determinar o tempo de fim mais tardar e mais cedo.
Indicar o caminho critico.
28-04-2023 HAIDER NOOR 26
Tarefa Condição de início DuraçãoA Início do projecto 3B 6C 5D 6E A,B terminados 4F B,C,D terminados 7G C terminado 6
28-04-2023 HAIDER NOOR 27
ATRIBUTOS DIRECCIONADORES DE CUSTO DO COCOMOcategoria
Atributo
produto RELY: Required software reliability (confiabilidade requerida do software)DATA: Data base size (Tamanho da base de dados)CPLX: product complexity (complexidade do software)
Computador
TIME: execution time constraint (restrições de tempo de execução)STOR: main storage contraente (restrição da memoria central)VIR´s: Virtual machine volatility (volatilidade da máquina virtual)TURN: tempo de rotatividade do computador
Pessoal ACAP: capacidade do analistasAEXP: experiência com a aplicaçãoPCAP: capacidade dos programadoresVEXP: experiência com a máquina virtualLEXP: experiência com a linguagem de programação
projecto MODP: prática da programação modernaTOOL: uso de ferramentas de softwareSCED: prazo requerido para o desenvolvimento
28-04-2023 HAIDER NOOR 28
EXERCÍCIO Foi solicitado o desenvolvimento de um sistema de banco de dados para m projecto de automacao de escritório. Segundo o documento de requisitos o sistema deverá ser composto por 4 módulos cujo tamanho foi estimado em: Módulo de entrada de dados: 0.6kloc Módulo de utilização de dados: 0.6kloc Módulo de consulta : 0.8kloc Módulos de relatórios: 1kloc
O gerente avaliou os 15 direcionadores do custo e chegou ao seguinte resultado Complexidade alta: 1.15 Armazenamento alto: 1.06 Experiencia baixa: 1.13 Capacidade de programadores baixa: 1.17
Calcular o esforço, produtividade, nr de pessoas e tempo
28-04-2023 HAIDER NOOR 29
PROCESSO DE DESENVOLVIMENTO
DE SOFTWARE
28-04-2023 HAIDER NOOR 30
Especificação
• Engenharia do sistema
• Engenharia de requisitos
• Especificação do sistema
Desenho
• Desenho da arquitectura
• Desenho das interfaces
• Desenho detalhado
Implementação
• codificação
Verificação e validação
• Testes unitários
• Testes de integração
28-04-2023 HAIDER NOOR 31
1. ESPECIFICAÇÃO Levantamento dos problemas, requisitos, especificidades, etc. Divide-se em Eng de Sistema – a análise da parte física do sistema e Eng de Requisitos – a análise da parte lógica do sistema. Especificacao do sistema – faz-se o levantamento do solução global para a resolução do problema.
28-04-2023 HAIDER NOOR 32
2. DESENHO É a representação gráfica do funcionamento do sistema. 1 – desenho da arquitectura 2 – desenho de interfaces 3 – projecto detalhado
28-04-2023 HAIDER NOOR 33
MODELOS DE CICLO DE VIDA DE
DESENVOLVIMENTO DE SOFTWARE
28-04-2023 HAIDER NOOR 34
MODELO DE QUEDA DE ÁGUA (CASCATA)
É aquele que não se passa para a fase seguinte sem que a anterior seja concluída, de todos os módulos.
Vantagem: É um modelo vantajoso em projectos pequenos
Desvantagens: Difícil manutenção. Considera a manutenção como uma fase.
Não facilita a produção de softwares de grandes dimensões onde os requisitos variam.
Não permite prototipagem.
Especificação
Desenho
Implementação
Verificação e validação
Evolução e manutenção
desenvolvimento
Validação
28-04-2023 HAIDER NOOR 35
MODELO DE PROTOTIPAÇÃO O avanço para a fase seguinte é feito similarmente ao modelo em cascata.
Vantagem: Resolve o inconveniente do modelo de desenvolvimento em cascata, em relação a comunicação com o cliente.
Tens como mostrar um exemplar ao cliente. (um demo, etc)
28-04-2023 HAIDER NOOR 36
MODELO ITERATIVO INCREMENTAL Consiste em repetir o processo de desenvolvimento várias vezes. (divisão do sistema em módulos). Foi desenvolvido para responder à ansiedade do cliente
Inconvenientes: O cliente pode se entusiasmar por uma versão experimental, pensando que este responde as suas
necessidades.
Especificação
Desenho
Implementação
Verificação e validação
Evolução e
manutenção
28-04-2023 HAIDER NOOR 37
28-04-2023 HAIDER NOOR 38
MODELO EM ESPIRAL Desenvolvimento é infinito. É o que mais se assemelha as formas de desenvolvimento actuais. Inclui gestão de riscos e todas as vantagens de todos outros modelos.
Cada quadrante é específico à uma fase de desenvolvimento. Cada ciclo passa por todas as fases de desenvolvimento.
Facilita desenvolvimento de sistemas em grande escala.
Desvantagem: Gestão de risco necessita de muita
experiencia.
planeamento
Gestão de Riscos
prototipação
ImplementaçãoTestes
Desenho
Codificação
Eng de RequisitosVerificação
28-04-2023 HAIDER NOOR 39
METODOLOGIA DE DESENVOLVIMENTO Orientada a objecto A base é UML. É a mais utilizada, principalmente em sistemas formais. É a que vamos utilizar. Facilita a manutenção, devido a produção de um grande volume de documentação.
Não existe DFD. (é especificado em vários outros diagramas) Estruturada O sistema é visto em forma de 3 componentes: base de dados, análise estruturada e a programação.
28-04-2023 HAIDER NOOR 40
PR: ENG. REQUISITOS Descrição de cada funcionalidade (diferentes processos) Ex: reservar passagem.
Caso de uso Limite de Pag: 5 Parte teórica: Casos de uso
28-04-2023 HAIDER NOOR 41
METODOLOGIA ÁGEIS DE DESENVOLVIMENTO São as mais perfeitas, se enquadram para qualquer tipo de projecto.
A documentação não é um parâmetro para medir o processo de desenvolvimento.
Baseia-se sobre os princípios: Interação entre os membros Aceitar facilmente mudanças do que aceitar um plano. Software em desenvolvimento do que acima da documentação. Colaboração com o cliente acima de contrato.
28-04-2023 HAIDER NOOR 42
METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO Inconvenientes: são pobres em documentação. Não há como gerir projectos com equipas de desenvolvimento muito grandes. (baseados em comunicação, quanto maior é a equipa mais difícil a comunicação)
28-04-2023 HAIDER NOOR 43
XP – (EXTREME PROGRAMING) A codificação é a base em relação as outras fases. É desenvolvida pelos diferentes princípios das metodologia respeitado valores e por meio de pratica.
Valores Comunicação-deve ser respondido por qualquer metodologia ágeis. Simplicidade – No que esta sendo feito ( deve se abortar a solução mais simples).
Feedback – pode ser dado para os programadores ou o cliente que ajuda eles a terem maior ideia sobre o sistema.
Coragem – não existe propriedade individual do código.
28-04-2023 HAIDER NOOR 44
PRATICAS DO XP Programação em pares. Propriedade colectiva do código. Integrações continuas. Semana de trabalho de 40 horas. Cliente no local. Padroes de condificacao
28-04-2023 HAIDER NOOR 45
CICLO DE VIDA Exploração – tenta se propor uma especificação para o problema, e se propõe uma arquitetura para o sistema
Planeamento inicial- Estorias- possíveis primeiras releses
Codificacao Desenvolve –se planos de testes , realização de testes, integrações
Producao Manutencao Morte
28-04-2023 HAIDER NOOR 46
PAPEIS Treinador - questões técnicas do projecto Rastreador – colecta métricas que possa permite a avaliação se o projecto esta a decorrer como deveria.
Programador – é que projecta, desenha, codifica e testa. Cliente – é que agrega valor ao negocio. Testador – pode ser um programador ou da parte do cliente. Consultor – Pessoas que tem conhecimento sobre uma determinada área.
28-04-2023 HAIDER NOOR 47
LIMITAÇÕES São maioritariamente desconhecidas: Equipas grandes -> baixo desempenho; Equipas tem um máximo de 12 membros;
Pouca documentação; Ausência do cliente; Pouco feedback?
28-04-2023 HAIDER NOOR 48
SCRUM – METODOLOGIA ÁGIL Iterativa incremental cujo foco é a gestão do projecto. Baseado em reuniões. O desenvolvimento começa com os clientes e usuários que definem aquilo que são as suas necessidades que na linguagem técnica do SCRUM chama-se backlog. O backlog é uma lista onde os clientes e usuários colocam aquilo que são os seus requisitos.
É aconselhado que seja utilizado uma outra metodologia em conjunto com o Scrum. A cada 30 dias a equipa deve entregar uma nova versão implementando novas funcionalidades.
28-04-2023 HAIDER NOOR 49
28-04-2023 HAIDER NOOR 50
SCRUM - CARACTERISTICAS Características Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente
interessados na saída); Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas; Planos frequentes de mitigação de riscos desenvolvidos pela equipe; Discussões diárias de status com a equipe; A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
O que fiz desde ontem? O que estou planejando fazer até amanhã? Existe algo me impedindo de atingir minha meta?
Transparência no planeamento e desenvolvimento; Reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o
progresso; Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema
não visto; Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" não
necessariamente significa "produzir mais".
28-04-2023 HAIDER NOOR 51
SCRUM – PAPEIS PRINCIPAIS Product Owner (dono do produto) O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de Scrum Master.
Scrum Master Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva.
Equipe (Development Team) A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 6-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e autoconduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe.
SCRUM – PAPEIS AUXILIARES Os papéis auxiliares em equipes Scrum são aqueles com nenhum papel formal e envolvimento frequente no processo de Scrum, mas, ainda assim, devem ser levados em conta.
Partes interessadas (clientes, fornecedores) Estas são as pessoas que permitem o projeto e para quem o projeto vai produzir o acordado benefício, que justifica a sua produção. Eles só estão diretamente envolvidos no processo durante as revisões sprint.
Gerentes (incluindo gerentes de projeto) Pessoas que irão configurar o ambiente para desenvolvimento de produtos.
28-04-2023 HAIDER NOOR 52
28-04-2023 HAIDER NOOR 53
CERIMONIAS DO SCRUM1. Planeamento do Sprint. (max.: 8hrs)
Todos os papeis devem estar presente. Parte 1 (Primeiras quatro horas): Team Product Owner: diálogo para priorizar o Product
Backlog. Parte 2 (Próximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando no
Sprint Backlog.
2. Reunião diária(max.: 15min) Equipa e Scrum Master Report de ponto de situação e impedimentos.
3. Revisão do Sprint (max.: 4hrs) Todos participam e convidados
4. Retrospectiva (max.: 3hrs) Faça melhorias contínuas de processos. Duas questões principais são feitas na retrospectiva
do sprint: O que correu bem durante a corrida? O que poderia ser melhorado na próxima sprint?
SM + Equipa
28-04-2023 HAIDER NOOR 54
ARTEFACTOS PRODUZIDOS PELA METODOLOGIAS SCRUM Artefacto - Aquilo que é fornecido no final do sprint. Product backlog – lista de funcionalidade do produto. Sprint backlog – lista de funcionalidade prioritárias. Estórias do usuário – descrições pelo usuário/product Owner a explicar certos itens para facilitar a percepção dos desenvolvedores.
O próprio produto – as várias iterações e a sua versão final
28-04-2023 HAIDER NOOR 55
SPRINT BACKLOG Para montar um bom backlog deve-se: Respeitar o tempo da reunião; É sempre bom que todos os membros envolvidos no projecto estejam presentes na reunião;
Definição do pronto - > especificar o que vai ser o produto final.
28-04-2023 HAIDER NOOR 56
CRISTAL/CLEARÉ uma metodologia ágil para projecto pequenos. As equipas são constituídas por um máximo de 6 pessoas. Maior parte dos processos são feitos de forma informal. Iterativo Incremental.Versões funcionais são entregues a cada 30 dias.
28-04-2023 HAIDER NOOR 57
RUP – RATIONAL UNIFIED PROCESS Desenvolvido pela IBM, para apoiar o desenvolvimento orientado a objectos.
Ajuda a tirar melhor vantagem do uso de UML
28-04-2023 HAIDER NOOR 58
BASEA-SE EM (CICLO DE VIDA):1. Iniciação ou concepção;
1. Define-se os principais casos de uso e das limitações do projecto;2. Define-se o escopo
2. Elaboração;1. Modularização do sistema2. Refinamento; 3. Elaboracao do plano do projecto;
3. Construcao;1. Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes
alfa2. Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem
"baseline“4. Transição;
1. Deployment do software2. Implantação e manutenção
28-04-2023 HAIDER NOOR 59
ICONIX Para projectos de dimensões médias. Uma juncão de XP(para codificação) e RUP (para modelação).
Quem é que faz o quê? R: diagrama de casos de uso Quais são os objectos e os relacionamentos que existem entre eles? R: diagrama de classes Que objectos são necessários para cada caso de uso? R: diagrama de robustez Como é que os objectos interagem e colaboram entre si, num caso de uso? R: diagrama de sequência e colaboração. Como são manipulados em tempo real aspectos de controle? R: diagrama de estados
28-04-2023 HAIDER NOOR 60
ENGENHARIA DE REQUISITOS
28-04-2023 HAIDER NOOR 61
ENGENHARIA DE REQUISITOS Requisitos – trata de tudo o que é necessário para responder as necessidades do usuário.
Engenharia de requisitos – a parte da engenharia de software reponsavel pelo levantamento, organização, representação e tratamentos de requisitos de um especifico software
Tipos de Requisitos Requisitos de usuários – é aquilo que o usuário quer Requisitos de sistema – é tudo que o sistema precisa para cumprir os requisitos do usuário.
28-04-2023 HAIDER NOOR 62
REQUISITOS DE SISTEMA Estão divididos em funcionais e não funcionais. São específicos ao sistema.
FUNCIONAIS São coisais que influenciam directamente na lógica de negócio.
Lógica de negócio, funções a ser implementadas.
NÃO FUNCIONAIS são factores externos que influenciam o funcionamento do sistema.
Questões de segurança, rede,
Para representar os requisitos funcionais é o diagrama de casos de uso.
28-04-2023 HAIDER NOOR 63
USE CASE Diagramas de casos de uso baseia-se em 3 elementos: Actor
Interacção
Caso de uso
28-04-2023 HAIDER NOOR 64
TIPOS DE RELACIONAMENTO Associacao é estabelecida entre uma actor e um caso de uso representado por uma interacao. Relaciona um actor a um caso de uso.
Verificar extracto
28-04-2023 HAIDER NOOR 65
TIPOS DE RELACIONAMENTO generalização – é como “herança” em POO. Esta divido em 2 partes : Entre actores – 2 ou mais actores que podem utilizar o mesmo caso de uso. Entre casos de uso
NB: não existe relação de generalização entre caso de uso e actor. Efectua vendas
Gerir stock
Venda a
grosso
Venda a
retalho
vendedor
gestor
28-04-2023 HAIDER NOOR 66
TIPOS DE RELACIONAMENTO Inclusão – é uma relação onde um caso de uso é dependente de outro. É uma condição. Todos os casos de uso devem ser respondidos antes de efectuar a tarefa principal
vendas Efectuar log in
<<includes>>
vendedor
28-04-2023 HAIDER NOOR 67
TIPOS DE RELACIONAMENTO Extensão – é um “if” em POO. Apenas tem que se responder a um caso de uso para efectuar a caso de uso principal. Não se pode ter uma relação de extensão sem condição.
Gerir stock
Actualizar stock
<<extends>>
gerentes Actualizar stockSe
Qtd<5
<<extends>>
28-04-2023 HAIDER NOOR 68
CASO DE ESTUDO - HELPDESK Listar os actores Administrador Técnico usuário
Identificar os casos de uso
Identificar qual actor esta conectado a qual caso de uso