engenharia de software

28-04-2023 HAIDER NOOR 1

ENGENHARIA DE SOFTWARE

Eng. Edvaldo Mahesh

[email protected]


NOTAS Exame escrito


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


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ê?


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.


CAP – I: INTRODUÇÃO A ENGENHARIA DE

SOFTWARE


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.


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,


CAP II – GESTÃO DE PROJECTOS DE

SOFTWARE


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)


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:


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.


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


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.


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)


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.


TABELA DE CONVERSÃO PF - LOC Linguagem LOC/PFC 162C++ 66Java 63SQL 40


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.


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


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;


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


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.


DIAGRAMA DE GANTT


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


Desenhar a rede de tarefar e determinar o tempo de fim mais tardar e mais cedo.

Indicar o caminho critico.


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


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


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


PROCESSO DE DESENVOLVIMENTO

DE SOFTWARE


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


• Testes unitários

• Testes de integração


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.


2. DESENHO É a representação gráfica do funcionamento do sistema. 1 – desenho da arquitectura 2 – desenho de interfaces 3 – projecto detalhado


MODELOS DE CICLO DE VIDA DE

DESENVOLVIMENTO DE SOFTWARE


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


Evolução e manutenção

desenvolvimento

Validação


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)


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


Evolução e

manutenção


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


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.


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


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.


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)


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.


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


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


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.


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?


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.


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


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.



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


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


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.


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.


RUP – RATIONAL UNIFIED PROCESS Desenvolvido pela IBM, para apoiar o desenvolvimento orientado a objectos.

Ajuda a tirar melhor vantagem do uso de UML


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


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


ENGENHARIA DE REQUISITOS


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.


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.


USE CASE Diagramas de casos de uso baseia-se em 3 elementos: Actor

Interacção

Caso de uso


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


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


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


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


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

engenharia de software

Documents