Material Disciplina Tópicos em Engenharia de SoftwareParte – 2

(Requisitos,Projeto,Implementação,Gerenciamento e Qualidade)

Prof. Wagner Santos C. de Jesuswsantoscj@gmail.com

Conceito de Engenharia de

Software

2

Conceito

É uma das áreas da Engenharia que tratados aspectos de produção de software e seus.

• Processos• Métodos• Técnicas• Ferramentas

3

Engenharia de SoftwarePráticas de desenvolvimento de software:

• Métodos de desenvolvimento;• Métodos de organização;• Métodos de controle de custos;• Método de medição;• Métodos de Testes

4

Princípios Fundamentais da

Engenharia de Software

5

Princípios da Engenharia de Software

1. Formalidade;2. Abstração;3. Decomposição;4. Generalização;5. Flexibilização

6

Definição dos Princípios

• Formalidade – Controle e Garantia de Desempenho.• Abstração – Identificação dos Aspecto importantes

ignorando os detalhes.• Decomposição - Subdividir o processo em atividades

específicas, atribuídas a diferentes especialistas.• Generalização – Implementar soluções que

possibilitem o processo de reutilização.• Flexibilização – Modificação do código com facilidade.

Exemplo processo de refatoração.

7

Mitos do Desenvolvimento

de SoftwareGerenciamento

8

Responsabilidade do Gerente de Software

1.Manter Orçamento;2.Evitar atrasos no cronograma;3.Elevar a qualidade.

9

Não se agarre à mitos.

Alguns Mitos• Mito: Já temos um livro cheio de padrões e

procedimentos para desenvolver software. Ele nãosupriria meu pessoal com tudo que precisam saber ?

• Realidade: O livro com padrões pode muito bem existir,mas ele é realmente utilizado?

• Os praticantes da área estão cientes de que ele existe?Esse livro reflete a práticas moderna da engenharia desoftware?

• É completo? É adaptável? Está otimizado paramelhorar o tempo de entrega, mantendo ainda o focona qualidade?

• Em muitos casos, a resposta para todas essasperguntas é não. 10

Mais Mitos

Mito: Se o cronograma atrasar, podemos acrescentarmais programadores e ficar em dia.

Realidade: O desenvolvimento de Software não é umprocesso mecânico como o de uma fábrica.

Isso somente poderá funcionar se de forma planejada ebem coordenada.

11

Mais Mitos

Mito: Se eu decidir terceirizar o projeto de software, possosimplesmente relaxar e deixar a outra empresa realizá-lo.

Realidade: Se organização não souber gerenciar econtrolar projetos de software, posso simplesmenterelaxar e deixar a outra empresa realizá-los.

12

Ciclo de Vida de um Sistema

13

Ciclo Diagrama do Ciclo de Vida

14

TransformaçãoFormal

Integração e Testes

EspecificaçãoFormal

Definição dos

requisitos

Implantação

Modelo a serconstruído para ocurso.

Processo Unificado Ciclo de Vida

15

Planejamento

Comunicação Modelagem

ConstruçãoEntrega

Transição

ElaboraçãoConcepção

Princípio da Comunicação1. Ouvir2. Prepare-se antes de se comunicar3. Facilitar as atividade (Reuniões com um líder)4. Comunicação de forma pessoal5. Anote e documente as decisões6. Esforce-se para conseguir colaboração7. Mantenha foco (crie módulos para a discussão)8. Faltando clareza, desenhe9. Uma vez de acordo, siga em frente. Se não a um

acordo siga em frente.10.Negociação não é uma competição nem um jogo.

Funciona melhor quando as duas partes saemganhando.

16

Princípios do Planejamento1. Entenda o escopo do projeto2. Inclua os envolvidos na atividade de planejamento3. Reconheça que o planejamento é iterativo.4. Faça estimativas baseadas no que se conhece5. Considere os riscos ao definir o plano6. Seja realista7. Ajuste particularidades ao definir o plano8. Defina como pretende garantir a qualidade.9. Descreva como acomodar as alterações10.Verifique o plano com frequência e faça os ajustes

necessários.

17

Princípios da ModelagemProjeto

1. O projeto deve ser alinhado para a modelo derequisitos

2. Considerar a arquitetura do sistema a ser construído.3. O projeto de dados é tão importante quanto o projeto

das funções de processamento.4. As interfaces (tanto internas quanto externas) devem

ser projetadas com cuidado.5. O projeto da interface do usuário deve ser voltado às

necessidades do usuário, mas ele sempre deveenfatizar a facilidade de uso.

6. O projeto no nível de componentes deve serfuncionalmente independente.

18

7. Os componentes devem ser relacionados livrementetanto entre componentes quanto com o ambiente externo.

8. Representação de projetos (modelos) devem ser de fácilcompreensão.

9. O projeto deve ser desenvolvido iterativamente.10. A criação de um modelo de projeto não exclui uma

abordagem ágil.

19

Observação

Princípios da Construção ePrincípios da Entrega

Somente serão relevantes naimplementação física do projeto.

20

Conceito de Requisitos

Requisitos são objetivos ou restriçõesdeterminadas por clientes e usuários quedefinem as diversas propriedades dosistema.

Requisitos são características do Software.

21

Tipos de Requisitos

• FuncionaisRequisito que pertencem ao software

• Não FuncionaisRequisitos que pertencem aarquitetura do software.

22

Exemplo Requisitosnão Funcionais

• A base de dados deve ser protegida apenas paraacesso de usuário autorizado.

• O tempo de resposta do sistema não deveultrapassar a quinze segundo.

• O Software deve ser construído para funcionar emrede local.

• O tempo de desenvolvimento não pode ultrapassara 10 semanas.

23

Objetivo dos Requisitos

O objetivo da definição dos requisitos éespecificar o que o sistema deverá fazer edeterminar os critérios de validação queserão utilizados para que se possa avaliarse o sistema cumpre o que foi definido.

24

Modelo de especificação de Requisitos de Software

25

Software requeriments specification (SRS)

SRS : Vem a ser um artefato criado quando umadescrição detalhada de todos os aspectos do software aser construído deve ser especificada antes do projetocomeçar.

26

Sumário (SRS)

1. Introdução2. Descrição geral3. Características do sistema4. Requisitos de interfaces externas5. Outros requisitos não funcionais6. Outros requisitos

27

Princípios da modelagem de requisitos

1. O universo de informações de um problema deve serrepresentado e compreendido.

2. As funções executadas pelo software devem serdefinidas.

3. O comportamento do software (consequência deeventos externos) deve ser representado.

4. Os modelos que representam informação, função ecomportamento devem ser divididos de modo arevelar detalhes em camadas (ou de maneirahierárquica).

5. A análise deve partir da informação essencial paraos detalhes da implementação.

28

Objetivo da Prototipação

• Exploratório• Experimental

29

Exemplo RequisitosFuncionais

• O Software deve possibilitar a aquisição darenda anual do contribuinte e calcular o impostode renda usando as alíquotas estabelecidas natabela de alíquotas.

• Deverá ser emitido o relatório de venda a cadaquinze dias.

• O usuário deve informar seu RA e confirmar asseu nome, para realizar, sua inscrição no evento

30

Exploratória

Permite esclarecer requisitos dos usuárioscom respeito ao sistema futuro. Permitindoao usuário emitir informações e sugestõesmais precisas tornando-se parceiros.

Exemplo:

Acessibilidade;Operabilidade;Portabilidade de dados 31

Experimental

É quando a prototipação foca aspectos técnicos do desenvolvimento:

Exemplo:

- Arquitetura;- Comunicação com outros dispositivos

32

Tipo do Protótipo

Sistema Piloto: É usado com propósito ilustrativo,Esse sistema deve ser instalado no ambiente deaplicação e experimentado com os usuários.

33

Planejamento do Desenvolvimento

(PD)

34

PD (Consiste nas Fases)

1. Análise de Risco2. Definição de um cronograma3. Aquisição de Software4. Reengenharia5. Planejamento Organizacional6. O Plano de Software

35

Análise de Risco

Atividade baseada na realização de quatrotarefas conduzidas de forma sequêncial:

1. Identificação2. Projeção3. Avaliação4. Administração

36

Identificação dos Riscos

1. Risco de projeto – São relacionados diretamente com oprocesso de desenvolvimento (orçamento, cronograma,pessoal).

2. Risco Técnico – Consistem em problema na(Implementação, Manutenção, Interface, plataforma deimplementação).

3. Risco de produto – São problemas que podem ocorrena inserção do software no mercado, Exemplo(Ultrapassado, Inadequado ou quando não háinteresse).

37

Projeção dos Riscos

Basicamente duas questões:

• Qual probabilidade que o risco ocorradurante o projeto.

• Quais as consequência dos problemasassociados aos riscos.

38

Projeção dos Riscos

As respostas a estas questões podem ser obtidasbasicamente a partir de quatro atividades:

1. Estabelecer uma escala estimada de ocorrência derisco;

2. Estabelecer e documentar consequências do risco;3. Estimar impactos do risco sobre o projeto e sobre o

software (produtividade e qualidade).4. Anotação da precisão global da projeção de riscos

39

Avaliação dos Riscos

Verificar se o risco afeta:

• Custo • Prazo• Desempenho

Determinar um (Breakpoint).40

Administração

Administração, tem como, tarefamonitorar os riscos.

Usar ferramentas e parâmetros paramensuras custos e prazos.

- Cálculos Estatísticos;- Ferramentas de plotagem de Gráficos;- Processos de simulação.

41

Ilustração da situação de dois níveis de risco(Custo e Prazo)

42

Ultrapassagem dos Custos

Ultrapassagemdos Prazos

Ações para minimizar problemas (Custos e Prazos)

• Reunir a equipe para determinar causas da rotatividade de pessoal.

• Tomadas de providências para eliminar e reduzir as causas.

• No inicio do projeto pressupor que rotatividades poderam ocorrer e se prevenir quanto a isso.

• Definir padrões de documentação• Realizar revisões do trabalho de forma que mais de uma

pessoa estejam envolvidas;• Estar informados sobre todas as atividades envolvidas• Definir um membro da equipe que possa servir de

backup para profissionais mais críticos.43

Plano de Administração de Monitoração de Risco

Todo o trabalho efetuado na tarefa de Administração deRisco é registrado num documento denominado Planode Administração e Monitoração de Riscos.

Importante: Definir Cronograma

44

Montagem do Cronograma• Montar a EAP (Estrutura Analítica do Projeto);• Listar atividades;• Estimar duração das atividades;• Definir Recursos das atividades;• Definir dependências entre as atividades;• Definir calendário para os recursos;• Definir data inicial do projeto;• Montar cronograma em uma ferramenta;• Nivelar recursos;• Identificar e analisar o caminho crítico;• Traçar uma linha de base;• Iniciar o monitoramento e controle do projeto.

45

Conceito Gerenciamento de

projetos de software

46

Atividades de comunicaçãoem Projetos Simples

• Desenvolver uma lista de questões paraesclarecimento.

• Reunir-se com envolvidos para esclarecer asquestões pendentes.

• Desenvolver conjuntamente uma basedocumentada do escopo.

• Revisar a base considerando todos osenvolvidos.

• Alterar a base conforme o necessário.

47

Definição das características-chaves

do projeto.

48

O principio W5HH (Boehm,1996)

49

(What)O que

(Why)Por que

(When)Quando

(Who)Quem

(How)Como

(Where)Onde

(Howmuch)Quanto

O principio W5HH (Boehm Barry,1996)

50

(Why) Por que o sistema está sendo desenvolvido?(What) O que será feito?(When) Quando será feito?(Who) Quem será responsável por uma função?(where) Onde se posicionam organizacionalmente?(How) Como será realizado o trabalho técnico e gerencialmente?(How much) Quanto de cada recurso será necessário?

Projeto propriedade coletiva

“Propriedades coletivas nada mais são do que uma ilustraçãoda idéia de que os produtos devem ser atribuídos à equipe enão aos indivíduos que compõem a equipe” (Jim Highsmith).

51

Conceito Grupo de Projeto

Envolvem :

• Planejamento;• Monitoramento;• Controle de Pessoas;• Processos;• Eventos

52

Planejamento de Projeto

53

Pessoas

Produto

Processo

Projeto

Gerenciamento de ProjetoSoftware

Modelo de Liderança (Pessoa)

Modelo MOI (Weinberg, 80).

• Motivação• Organização• Idéias ou Inovação

54

MotivaçãoCapacidade de estimular o pessoaltécnico a produzir com o melhor dasua habilidade.

55

Organização

A habilidade para moldar os processos jáexistentes (ou inventar novos) que vãocapacitar o conceito inicial a sertransformado em um produto final.

56

Idéias ou Inovação

A habilidade de estimular pessoas a criar eserem criativas, mesmo quando estiveremtrabalhando de acordo com padrõesestabelecidos para um produto ou aplicativo desoftware específico.

57

Equipe de Software

58

Paradigma Organizacionais para Equipes de Software

59

Paradigma Fechado

Paradigma Randômico

Paradigma Aberto

Paradigma Sincronizado

Paradigma Fechado

Estrutura uma em termos de umahierarquia de autoridade tradicional.

60

Paradigma Randômico

Estrutura uma equipe vagamente edepende da iniciativa individual de seusmembros.

61

Paradigma AbertoEstrutura uma equipe de forma a adquiriralguns controles associados aoparadigma fechado possibilitando amescla com paradigma randômico.

62

Paradigma SincronizadoO paradigma sincronizado baseia-se nacompartimentalização natural de um problema eorganiza os membros da equipe para trabalharnas partes do problema com poucacomunicação entre si.

63

São Paulo Rio Janeiro