32
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br Engenharia de Sistemas IV Prof. Erwin Alexander Uhlmann Engenharia de Software e UML UHLMANN, Erwin Alexander. Engenharia de Sistemas IV. Instituto Siegen. Guarulhos, 2012.

Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann – Sumário Introdução

  • Upload
    lamnhan

  • View
    224

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Engenharia de Sistemas

IV

Prof. Erwin Alexander Uhlmann

Engenharia de Software e UML

UHLMANN, Erwin Alexander. Engenharia de

Sistemas IV. Instituto Siegen. Guarulhos, 2012.

Page 2: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Agradecimentos

Agradeço à minha esposa Kátia por entender

minha ausência, meus pais Mirtes e Günter por

terem criado meu caminho, aos meus alunos que

viabilizaram este trabalho e a todos os autores

de livros e bibliotecas que consultei para que

pudesse devidamente embasar este.

Page 3: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Sumário

Introdução ........................................................................................................................2

Engenharia de Software e de Sistemas .......................................................................... 3

O que é um software? ................................................................................................. 3

O que é Engenharia de Software? .............................................................................. 4

Métodos de ES ............................................................................................................. 4

Atributos de software ................................................................................................. 5

Desafios da ES .............................................................................................................. 5

Independência Funcional ........................................................................................ 5

Baixo Acoplamento ................................................................................................. 5

Alta Coesão .............................................................................................................. 6

Gerenciamento de Engenharia de Software ...................................................................7

Sistemas Sociotécnicos ................................................................................................7

Exercício ....................................................................................................................... 8

Propriedades Emergentes ...................................................................................... 8

Engenharia de Sistema ........................................................................................... 10

Definição de Requisitos de Sistema ....................................................................... 11

Requisitos ........................................................................................................................ 12

Escopo ......................................................................................................................... 12

Viabilidade ................................................................................................................... 13

Tipificação de viabilidade ....................................................................................... 15

Obtenção dos requisitos ............................................................................................ 15

Obtenção de requisitos .......................................................................................... 16

Tipos de Requisitos................................................................................................. 17

Processo de Software .................................................................................................... 19

Modelo Cascata .......................................................................................................... 19

Page 4: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Desenvolvimento evolucionário ............................................................................... 20

Engenharia de Software baseada em Componentes ............................................... 21

Teste de Software .......................................................................................................... 23

Modelo “V” de teste de software ............................................................................. 23

CMMI .............................................................................................................................. 26

Framework de aprimoramento de processos ......................................................... 26

Bibliografia ..................................................................................................................... 29

Índice de Figuras

Figura 1 - Modelo Cascata. Sommerville (2007) ............................................................ 19

Figura 2 - modelo evolucionário ..................................................................................... 21

Figura 3 - Baseado em componentes ............................................................................ 22

Figura 4 - Modelo CMMI ................................................................................................ 28

Índice de tabelas

Tabela 1 - Áreas de processo do CMMI ......................................................................... 26

Page 5: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

2

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Introdução

A Engenharia de Software é o ponto crucial para o profissionalismo. Criar sistemas

de forma amadora é simples, quase como criar programando, mas depois de um

ano alterar, progredir ou simplesmente fazer a manutenção num programa se

mostra difícil e muitas vezes impossível.

O objetivo deste trabalho é mostrar como a engenharia de software pode ser

simples e rápida de fazer para garantir maior qualidade e profissionalismo à seus

projetos.

Para quem busca entender a engenharia de software além da teoria, com projetos,

este trabalho pode ajudar muito!

Divirta-se!

Page 6: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

3

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Engenharia de Software e de Sistemas

O que é um software?

Para entender o software vamos primeiro disseca-lo.

A informática foi criada com base em bits e Bytes, a coleção deles, a palavra. Com as

linguagens de baixo nível foi possível cria sequencias lógicas de execução, os

scripts. Ao conjunto de scripts foi dado o nome de software.

Mas um software pode ser mais do que a coletânea de scripts. Os dados de

configuração, documentação, e arquivos que associados permitam o software

funcionar adequadamente.

A Microsoft é uma empresa de engenharia, a Apple também tem sua área de

engenharia, a Sony, a Nokia e muitas outras empresas de ponta. O que você deve

pensar para poder chegar onde elas dominam? Engenharia!

Apesar de desenvolver produtos genéricos, como o Windows, o MS Office, o

facebook, e o AutoCAD, as empresas podem desenvolver produtos específicos.

Os softwares genéricos são sistemas que atendem a maioria dos computadores de

uso genérico e seus desenvolvedores é que controlam as especificações enquanto

os sob encomenda são desenvolvidos para um cliente específico ou para um

computador específico e as necessidades são informadas pelo comprador.

Algumas empresas desenvolvem ainda um terceiro tipo, o software genérico

personalizável, como é o caso das empresas de ERPs, como a SAP ou a MicroSiga

que adaptam partes de seus softwares às especificidades dos clientes.

Exemplo:

Um site que tenha um sistema de login e senha. O sistema de login e senha pode

funcionar independente do restante do site? Ele depende de outros dados como de

um banco de dados de usuários de senhas? Os dados exibidos na tela dependem da

programação?

Page 7: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

4

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

O que é Engenharia de Software?

Se entendermos o que software, então a Engenharia de Software é a disciplina

ligada à produção de software.

A engenharia se vale de métodos sistemáticos, esquemas e regras relacionadas ao

funcionamento do software, desde sua produção até seu declínio ou como também

é conhecido vulgarmente como abandonware. Os softwares descartados e que

eventualmente não funcionarão mais por falta de hardware ou outro meio que o

permita, como é o caso do Windows 3, jogos do Atari ou softwares baseados em

arquiteturas de sistemas operacionais antigas.

E qual a diferença entre engenharia de software e de sistemas?

A engenharia de sistema está baseada no desenvolvimento completo, que inclui

hardware, software e peopleware, enquanto a engenharia de software é parte

integrante deste processo. A Ciência da Computação abrange a engenharia de

sistemas.

Uma pergunta simples que frequentemente é negligenciada e, portanto,

determinante para um projeto, é quanto ao custo. Quanto custa um processo de

software?

Isto depende dos profissionais envolvidos, o tempo e a quantidade deles em cada

fase. No modelo cascata, a especificação dura cerca de 20% do tempo total de

processo de um software, o projeto cerca de 25%, o desenvolvimento, cerca de 20% e

a integração e testes, cerca de 35%. Cada profissional pode ter um custo, e cada fase

uma quantidade de profissionais.

Métodos de ES

Cada tipo de software pode ser produzido com um determinado modelo, como o de

Análise Estrutura, comum na década de 1970, o de Orientado à Funções, na década

de 1980 e por fim, com o desenvolvimento da UML, a Orientada à Objetos (OO), a

partir da década de 1990.

Page 8: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

5

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Atributos de software

Característica do produto Descrição

Facilidade de Manutenção O SW deve ser desenvolvido para que a manutenção, alteração e/ou evolução atendam as necessidades de mudanças de mercado. O sistema deve ser pensado em independência funcional, baixo acoplamento e alta coesão. Uma página HTML envia os dados para a página com a programação ou modelo de negócio (PHP) e esta envia para o Banco de Dados.

Confiança Confiabilidade: Funcionamento até a falha; Proteção: Divido em camadas para que não haja acesso; Segurança: Sistema que permita o acesso por meio de chave;

Eficiência Software que utilize o mínimo do computador, como códigos simplificados (OO), e tempo de resposta reduzido.

Usabilidade Que permita o acesso ao usuário para qual foi projetado, sem esforço demasiado ou dificultado.

Desafios da ES

A ES deve pensar sempre no desenvolvimento de softwares com Independência

Funcional, baixo Acoplamento e Alta Coesão.

Independência Funcional: Como diz o nome, o funcionamento não

deve depender de outras partes, está ligado à modularidade, ocultação de

informações e abstração. A ocultação de informações se dá pelo fato de não alocar

dados sigilosos como senhas no mesmo script ou módulo. Abstração é a

consideração de apenas uma das partes do software em detrimento do todo, isto é,

ele deve ser pensado apenas como aquele módulo, sem se considerar o programa

inteiro.

Baixo Acoplamento: É a medida de interdependência entre dois ou mais

módulos. Se pensarmos num software com classes, qual a interdependência entre

as classes? E se uma dessas classes for removida, o script continuará a funcionar?

Page 9: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

6

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Alta Coesão: É a medida da força funcional entre módulos, isto é, quando um

módulo disponibilizar dados o outro que precisar poderá utilizá-lo sem perdas,

falhas ou necessidade de tratamento de dados para poder utilizar.

Então, se um programa for elaborado com independência funcional, poderá ser

utilizado mesmo que outros módulos não estejam disponíveis, desde que ele tenha

baixo acoplamento ou que não dependa de outros módulos para funcionar.

Diferente da independência funcional que prevê o funcionamento e fornecimento

de dados independente o acoplamento prevê que módulos poderão ser instalados

ou removidos sem afetar o funcionamento do todo e por fim, a alta coesão indica o

fornecimento de dados deste módulo no formato correto de leitura.

O desafio da heterogeneidade pressupõe que os softwares devem estar cada vez

mais disponíveis em sistemas distribuídos, como na web e se adaptar a sistemas

legados sem que o usuário tenha que trocar de ambiente entre os novos sistemas e

os antigos ou que a empresa tenha que ter mais de um sistema, como sistemas de

apoio.

O desafio da entrega é sobre a necessidade de desenvolvimento de forma cada vez

mais ágil e com menor impacto ao cliente, ainda que se considerassem as mudanças

de escopo do projeto.

Desafio da confiança que é desenvolver softwares que transmitam, armazenem e

seja apenas o desejado, em especial em sistemas web em que se não se tem certeza

sobre o que está sendo transmitido, armazenado nem se a página visitada é

realmente a desejada, como em sites de bancos.

Page 10: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

7

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Gerenciamento de Engenharia de Software

Sistemas Sociotécnicos

Em Engenharia de Software é preciso pensar num sistema composto pelo próprio

software, o hardware e as pessoas que irão utilizá-lo, ou seja, peopleware, o

componente humano.

Um sistema é um conjunto de componentes interrelacionados criados para atingir

um determinado objetivo.

Para planejar um sistema um sistema é preciso pensar no componente técnico,

como as especificações de hardware e software e no levantamento de processos,

regras internas da organização, leis, entre outros fatores que rejam as pessoas.

Então num levantamento para um sistema sócio técnico é preciso pensar:

No âmbito da empresa:

Situação Descritivo técnico

Atual

Quais são os processos que o setor/função faz? (Funções)

Como estes processos são feitos? (manualmente, Excel...)

De onde vêm os dados? (Contabilidade, RH, Cliente...)

Qual o formato? (Papel, verbal, txt...)

BPM, leis, regras.

Desejada

Como os itens levantados na situação atual irão ficar?

Instalação de um sistema integrado com interfaceamento via XML

entre os sistemas das filiais.

Motivadores

Por que mudar?

Agilidade logística, de vendas, tomada de decisão, controle, redução

de custos, etc. Isto norteará o projeto!

No Âmbito do Software:

Situação Descritivo técnico

Atual Quais os softwares utilizados? Qual formato exportam arquivos?

Page 11: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

8

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Qual a plataforma? (Windows, Linux, Oracle...)

Desejada

Como os itens levantados na situação atual devem ficar?

Instalação de um sistema integrado com interfaceamento via XML

entre os sistemas das filiais.

Motivadores

Por que mudar?

Agilidade logística, de vendas, tomada de decisão, controle, redução

de custos, etc. Isto norteará o projeto!

Exercício

Crie exemplos próximos da realidade de uma pizzaria comum de bairro. Ela tem o

processo de atendimento, cocção da pizza e entrega via motoboy.

No atendimento há um computador simples com 3 anos de uso e um sistema de

código aberto (freeware) de controle de pedido, cadastro de clientes, pedidos por

entrega, calculo de valores, e alguns relatórios de tempo de entrega, total de

pedidos, produto mais pedido, entre outros, em Excel.

O cliente deseja melhorar seu sistema. Crie um projeto que permita isto conforme o

já estudado.

Propriedades Emergentes

A propriedade emergente de um sistema é a somatória das partes, isto é, cada

parte tem sua função, mas o conjunto é mais que a soma das funções, é a

propriedade que emerge do sistema. 1 + 1 = 3!

O descritivo das propriedades pode ser feita separadamente do emergente.

Uma roda serve para girar, com pneu, serve para absorção de irregularidades e

tração, o pedal recebe a força motriz e em conjunto com a corrente que transmite

para a coroa, transfere esta força para a roda. O chassi (corpo) junta as partes e a

bicicleta serve para transportar de forma rápida e leve uma pessoa, sendo isto sua

propriedade emergente.

As propriedades emergentes são divididas em funcionais e não-funcionais.

Page 12: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

9

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Funcionais: Para que se destina um software. Sua função. Somar, imprimir,

desenhar, gerenciar backup, etc.

Não-funcionais: Qual o comportamento do software. Como ele realiza as

funções. Sendo:

Volume: Espaço ocupado em disco, medido em Bytes. Um sistema distribuído pode

ocupar 10MB em um servidor, 2MB em outro e mais 1MB nos clientes, sendo assim,

o volume total é de 10 + 2 + (1 x nº de clientes).

Confiabilidade: A confiabilidade do sistema depende de seus componentes. As

interações podem causar situações inesperadas e falhas. Ela é medida pelo tempo

de uso normal até a falha. Se o sistema em produção (software pronto, instalado e

com pessoal treinado), funciona normalmente, desde seu início até a data atual, 2

meses depois, a confiabilidade é de 2 meses. Corrigida a falha, a confiabilidade deve

ser novamente contada, desde a correção.

Proteção: É a capacidade de resistir a ataques. Um pouco diferente da

confiabilidade, a proteção é de difícil mensuração. Não se pode medir a proteção

até sua invasão. Se for invadido, não está protegido. Sua maior dificuldade não está

em criar mecanismos e meios de proteção para ataques conhecidos, mas para os

desconhecidos.

Facilidade de reparos: Reflete a capacidade de resolver uma falha em razão do

tempo e da complexidade. Isto depende da capacidade de diagnosticar, acessar o

componente e corrigir o problema. Ex.: Para diagnosticar o próprio sistema pode

informar erros com mensagens, acessar componentes de forma rápida com

separação dos componentes em camadas e corrigir com documentação adequada,

backups e sistemas de restauro.

Usabilidade: Facilidade de uso. Quantos cliques para acessar a informação, gravação

em tempo real, histórico, meios alternativos de operação (alternativos ao mouse,

teclas de atalho, disponibilidade de informações no mesmo lugar, etc.)

Page 13: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

10

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Confiabilidade de HW: Qual a estatística de falhas? Qual a probabilidade? Qual o

tempo de conserto?

Confiabilidade de SW: Uma falha de HW pode ser intermitente, mas no SW, que não

desgasta, deve ser recorrente e persistente. Qual a probabilidade de falha? Quanto

tempo para conserto.

Confiabilidade de PW: Probabilidade de erro do operador. O que pode gerar erro ou

engano? Cuidado com a linguagem. Gravar ou Executar?

Engenharia de Sistema

A Engenharia de Sistemas abrange as seguintes atividades:

Especificação: Requisitos de software, hardware e pessoas;

Projeto: UML, documentação, arquitetura de HW, etc;

Implementação: Criação de ambiente de teste para de produção, ajustes e

treinamento;

Validação: Consequência da Implementação, homologação;

Manutenção: Rotina de limpeza de logs, de arquivos excluídos, e atividades em HW;

Upgrade: Melhorias no sistema. Deve obedecer aos requisitos funcionais e não-

funcionais;

Definição de

Requisitos

Projeto do

sistema

Desenv. De

subsistemas

Integração

do sistema

Instalação

do sistema

Evolução do

sistema

Desativação

do sistema

Page 14: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

11

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Definição de Requisitos de Sistema

Os requisitos são as definições do que o sistema deverá fazer, suas funções, e suas

propriedades essenciais e desejáveis.

Requisitos funcionais abstratos: Especifica as propriedades do projeto sem se

preocupar em como fazer, mas com o que fazer, como:

Elaborar um sistema que integre o sistema administrativo do colégio, o

cadastro dos alunos, professores, disciplinas, notas, faltas e

histórico escolar, uma rede social, uma wiki e um site, com interface

web.

Estas especificações NÃO SÃO requisitos funcionais abstratos:

O sistema deverá ter um Banco de Dados com dados dos alunos, das

disciplinas cursadas, em curso e possíveis de cursar, os professores,

salas, diário de sala, histórico do aluno, faltas e notas.

Propriedades de sistema:

São as propriedades emergentes do sistema como segurança, disponibilidade,

desempenho.

Exemplo:

O sistema deverá contar com segurança para uso de cartão de crédito,

envio de senhas, estar disponível 24h por dia, 7 dias por semana e

como se trata de um e-commerce, ter alto desempenho para envio e

recebimento de dados.

Características que não devem ser apresentadas no sistema:

Para trabalhadores em uma linha de produção, o sistema NÃO deverá apresentar

informações em excesso, não deverá ver informações sobre dados do cliente, ou

ainda sobre as finanças da empresa.

Site do colégio Rede social

Wiki Sistema de

gestão

Page 15: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

12

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Requisitos

O problema a ser resolvido é estabelecer uma linguagem compreensível entre o

cliente e o programador, o desenvolvedor do software, de modo formal.

A Engenharia de Sistemas é ampla, abrangente e abstrata e a Engenharia de

Software é técnica, específica e concreta. A primeira não especifica como fazer, mas

o quê fazer e a segunda não é compreensível pelo cliente ou ele não é capaz de

especificar corretamente para o desenvolvimento.

Para resolver o problema de comunicação, a análise de requisitos pode ajudar na

solução. Para tanto é preciso elaborar:

Escopo;

Estudo de viabilidade; e

Obtenção dos requisitos.

Escopo

O escopo deve ser elaborado com o cliente, veja um modelo:

Item Conteúdo Patrocinador Quem solicitou ou o pagador.

Gerente Identificação, responsabilidades e autoridade

Organograma do projeto Organograma

Time do projeto Relação de recursos humanos

Comitê executivo Responsável pela análise e aprovação de mudanças

Descrição do projeto Do que se trata o projeto Objetivo do projeto Por que e para quê será feito este

Engenharia de

Sistemas

Engenharia de

Software R

Page 16: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

13

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

projeto? Justificativa do projeto Em função dos problemas e das

soluções propostas (contidos no escopo), atende o objetivo?

Produto do projeto Pré-projeto, simples e descritivo Expectativa do cliente Conformidade com o termo de abertura,

no prazo e custos estabelecidos Restrições Custo, prazo, pessoas, equipamentos,

etc. Premissas As pessoas poderão se adequar, a

comunicação será por meio tal, qte de horas/semana dos recursos, etc.

Limites do projeto O que será feito e não será feito? Estrutura analítica do projeto Esquema visual do que será feito

Principais atividades e estratégias Descritivo da estrutura analítica

Entregas O que será feito? SW, HW, documentação

Orçamento Quando e quando será pago?

Plano de entregas O que será e quando será entregue (documentos)

Riscos iniciais Falta de mão de obra, leis, erros de execução, etc.

Registro de alterações Data, quem modificou, quem aprovou e o que mudou

Viabilidade

O estudo da viabilidade permite criar indicadores para decisão de continuar no

planejamento e desenvolvimento do software ou não, bem como apontar soluções

alternativas para a solução de problemas de desenvolvimento. Para tanto, a análise

deve conter:

O projeto pode ser feito?

o Quais linguagens estão envolvidas?

o Qual hardware é necessário?

o As pessoas envolvidas têm as possuem as competências essenciais

para elaborar o projeto?

O produto final terá valor para o cliente?

o Valor é medido pela garantia e utilidade, que são:

Garantia é servir para o uso sem variações de desempenho;

Ex.: De 100 vezes que você utilizou seu computador, quantas

Page 17: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

14

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

ele travou (por hardware) ou não iniciou o sistema

operacional?

Utilidade é servir para um propósito ou melhorar o

desempenho médio;

Ex.: de todos os dias da semana, quantas vezes você utilizou

seu computador pessoal? Das vezes que você utilizou, quanto

tempo a menos você levou para elaborar suas tarefas?

o Identificação dos problemas e possíveis soluções

Identificação e qualificação de problemas

Gravidade Baixa Impactos dentro dos planos contingenciais de autonomias dos gerentes, não impacta no tempo.

Média Impactos afetarão o tempo de entrega em até 10%, o custo acima das autonomias gerenciais

Alta Afetará o tempo em mais de 10% do prazo e o custo com acionamento do Gerente ou Sponsor. Qualificação

Baixa (até 20% de prob.) 1 em cada 5 vezes pode ocorrer

Atraso no processo de codificação do sistema (programação) por transito (trabalho no cliente) em mais 1h por dia. Baixa gravidade, pois não afeta o processo como um todo e baixa probabilidade de ocorrer.

Perda de um programador durante o processo, no segundo quartil. Probabilidade! Gravidade média, pois deverá haver novo treinamento e interação com o projeto. Baixa probabilidade, pois os salários são adequados, a mão de obra não é específica ou o projeto é de linguagem única.

Falha no levantamento dos requisitos que desqualifiquem o projeto, mudança de lei, ausência ou demissão de um dos dois programadores (50%). Gravíssimo! Mas a probabilidade de ocorrer é baixa.

Média (21% à 60%) Até 3 em cada 5 vezes ocorre.

Alta (> que 60%) Mais do 3 em 5 vezes ocorre

Se o local fica em área alagável, a probabilidade de alagamento é alta no verão e se for exatamente lá que ocorrer o trabalho no estilo Just In Time... Gravíssimo!

Identificação de soluções e prioridades

o Definição da solução adotada

Page 18: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

15

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Estudo e planificação da estrutura organizacional, usuários, softwares

existentes, políticas, funções, cargos, missão, visão, objetivos, etc.

Tipificação de viabilidade

Operacional

Índice de funções solicitadas (processos organizacionais) e os entregues

adequadamente. Caso hajam inconsistências, é preciso levantar se foram problemas

de requisitos, de execução ou de mudanças realizadas depois do projeto, para tanto

é preciso documentar e datar.

Técnica

Quantos recursos devem ser envolvidos para solucionar um problema. Qual o valor

(financeiro e de mais valia) do sistema?

Cronograma

Tempo de realização do projeto x recursos = custo do projeto (R$)

Econômica

A organização pode determinar o custo do processo, você pode determinar o

ganho em tempo para realizar o cálculo de custo x benefício.

Obtenção dos requisitos

Para obter bons requisitos é preciso uma visão top down ou bottom up. Isto vai

depender do tipo de sistema e como se deve estrutura-lo.

Para se elaborar os requisitos, podem ser consultados:

Clientes, para determinar o desejado;

Usuários, que utilizarão o sistema;

Administradores, para compreensão do modelo de negócio;

Pares, pessoas que conheçam o assunto ou especialistas na área para

validação;

Concorrentes.

Page 19: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

16

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Obtenção de requisitos

Modelo RAPITO

Requisitos, Análise, Projeto, Implementação, Teste e Operação;

Motivação: Como criar uma documentação com linguagem comuns para o cliente e

a equipe de desenvolvimento?

Técnicas de obtenção de requisitos

Entrevista estruturada, com formulários padrão;

Ata de Reunião de Entrevista Projeto: <<nome do projeto>> Presentes: Integrantes Ausentes: Data: Local:

Data: <<data da entrevista>>

Entrevistados: <<nomes e papéis dos entrevistados, separados por vírgula>>

Entrevistadores: <<nomes dos entrevistadores, separados por vírgula>>

Duração: <<duração no formato 00:00>>

Assunto: <<texto sucinto indicando o assunto principal da reunião>>

Objetivos: • <<texto descrevendo o objetivo 1 da entrevista>> • <<texto descrevendo o objetivo n da entrevista>>

Perguntas Formuladas: • <<listar as perguntas formuladas na ordem em que elas foram feitas ao entrevistado>>

Pontos Discutidos: • <<texto descrevendo alguma informação relevante capturada na entrevista>>

Workshop;

Estudo de cenários;

Casos de Uso;

Diagrama de Atividades;

Protótipos;

Etc;

Page 20: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

17

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Tipos de Requisitos

Requisitos Funcionais são assuntos de importância fundamental ou essencial

ao produto. Eles descrevem o que o produto tem de fazer ou que ações

processuais deve tomar.

Comumente são descritos em documentos como RF ou REF e acompanhado de

numerais sequenciados. RF01 ou REF02.

Requisitos Não Funcionais são as propriedades que as funções devem ter,

tais como desempenho, usabilidade, proteção, entre outros.

Comumente são descritos em documentos como RNF e acompanhado de numerais

sequenciados. RNF01.

Notações

Linguagem Natural Estruturada;

o Formulários;

o Uso da taxonomia; (uso adequado e descritivo das palavras). Ex:

Agregar valor: Agregar, juntar, somar. Valor: Garantia + Utilidade;

Garantia: Nº total de vezes de uso com sucesso. Utilidade: Nº total de

possibilidades de uso / nº efetivo de usos = taxa de utilidade. Assim:

X = (Nº de Funcionalidades do sistema legado);

Y = (Nº de uso + (nº de usos) + (nº possib. De uso / nº efetivo de uso));

Valor Agregado = Y – X

Linguagem de descrição de projetos

o Portugol, linguagem estruturada;

Notações gráficas

o IDEF0, UML, DFD, etc;

Modelo de Levantamento de Requisitos

Solicitante (Sponsor):

Page 21: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

18

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Usuários: Defina quem irá utilizar o sistema. A quem se destina.

Requisitos de Negócio(RN): Qual o objetivo do SW, por que a organização precisa

deste software, veja mais no Escopo.

Responsabilidade dos usuários: As responsabilidades devem estar alinhadas com as

funções do usuário.

Prioridades de desenvolvimento:

Prazos:

Responsável:

Checklist de Requisitos

Os requisitos podem e foram mensurados? Foram criadas as métricas para os

requisitos Funcionais e Não Funcionais?

O requisito viola alguma regra de negócio? Corrija o requisito!

É possível definir testes para os requisitos? Como?

Os requisitos seguem as referências?

o Especificação de Requisitos de Software (ERS);

IEEE/ANSI 830-1998;

Page 22: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

19

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Processo de Software

Numa fábrica de software, definimos os requisitos do software, documentamos,

especificamos a arquitetura, sua viabilidade e escopo. Passada esta fase é hora de

partir para o projeto.

O processo de software é um conjunto de atividades que leva à produção de um

software. Para compreender estes processos, é preciso entender que são

frameworks que abstraem de forma a se compreender o fim desejado, mas não o

refino (que é o inverso de abstração). Vamos aos modelos de processo de software.

Modelo Cascata

É o primeiro modelo desenvolvido para o processo de software. Considera as

atividades fundamentais do processo.

Figura 1 - Modelo Cascata. Sommerville (2007)

Exemplo

Requisitos – Site volátil

Projeto de sistema e SW

Interface do

Usuário

Sistema de

login e senha

Sistema

administrativo

Modelo de negócio

Banco de Dados

Page 23: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

20

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Implementação e teste – Após a identificação do sistema (projeto do sistema),

identifique os subsistemas e comece a codificar. Os testes são feitos para

verificação de cada subsistema ou unidade atende os Requisitos. UML, DFD, MER,

Algoritmo e codificação.

Integração e manutenção – Implementar os subsistemas no mesmo ambiente e

testar suas interações e o correto funcionamento. Se os requisitos forem

plenamente atendidos, pode-se liberar para o cliente.

Operação e manutenção – Esta fase pretende recolher dados e configurações em

funcionamento, em operação, para realização de manutenções e correções.

Geralmente é a fase mais longa.

Desenvolvimento evolucionário

Este desenvolvimento atende as necessidades conforme solicitação ou

atendimento ao cliente. Compreende o desenvolvimento inicial do software,

expondo os resultados ao usuário e refina-se com versões intermediárias até a

adequação final. Existem dois tipos de desenvolvimento evolucionário:

Exploratório – é desenvolvido com participação direta do cliente. O

desenvolvimento começa pelas partes compreendidas e evolui com a adição de

novas funcionalidades.

Prototipação – Quando o cliente não consegue entender plenamente ou não

consegue explicar adequadamente os requisitos do software. Desenvolve-se

atendendo mais adequadamente o sistema e demonstra-se para correções e

adequações.

O problema é que o processo geralmente é invisível, pois o tempo de produção é

tão rápido que não compensa a documentação e isto dificulta a cobrança e

mensuração do software e, devido as constantes mudanças a integridade pode ser

comprometida por não haver a correta compreensão das inter-relações dos

subsistemas.

Page 24: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

21

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Figura 2 - modelo evolucionário

Engenharia de Software baseada em

Componentes

Este método tem crescido cada vez mais, pois se baseia na análise dos

componentes reutilizáveis, isto é, a partir da análise dos requisitos, identificam-se os

componentes que possam ser reutilizáveis, como sistemas de impressão de

relatórios em PDF, exportação de dados em XML ou edição de dados.

Imprimir um relatório está diretamente ligado aos dados desejados, mas se a

programação for orientada a produzir o relatório independente do tipo de dado, ele

pode ser reutilizado.

Com este método é possível atender os requisitos e durante a análise, ainda em fase

de projeto, modificar de forma consistente os próprios requisitos. Veja figura 3.

Page 25: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

22

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Figura 3 - Baseado em componentes

Page 26: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

23

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Teste de Software

O objetivo do teste de software é encontrar falhas e erro no próprio software, nos

dados, na documentação ou nas saídas. Isto envolve o contexto e a análise dos

requisitos até o próprio teste.

O processo de teste de software tem duas metas distintas:

1. Demonstrar ao cliente o atendimento aos requisitos;

2. Descobrir falhas ou defeitos no software que apresentem falhas,

incorreções, dados indesejáveis ou não conformidade dos requisitos.

Para se realizar os testes de software, é importante eleger um Grupo de

Independente de teste de Software (GITS), que deverão tentar “quebrar” o

software. Este grupo deve estar limpo do projeto para se evitar vícios.

Modelo “V” de teste de software

Vamos pensar no modelo V, primeiro como uma sequencia.

1. Requisitos

2. Análise

3. Projeto

4. Implementação (codificação)

Teste de Sistema

Teste de Validação

Teste de Integração

Teste de Unidade

É possível entender que o lado esquerdo do gráfico ilustra a construção do software

e o lado direito seus testes. Após a codificação ou implementação é dado o início da

fase de teste de software.

O início dos testes, pelos GITS, deve começar pelos componentes, com o teste de

Unidade ou de Componente. Após todos os componentes apresentarem

comportamento adequado, isto é, não há falhas de scripts, de interface, e os dados

são processados adequadamente. No teste de componente ou unidade é feito o

uso do método caixa branca, que demonstra os passos percorridos para se alcançar

aquele resultado. Passa-se então para a fase de teste de integração.

Page 27: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

24

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

A Integração promove o encontro dos módulos, assim, o componente A que

fornece dados para o B são verificados em seu workflow. Se os dados estão sendo

entregues adequadamente. Esta é uma importante fase que pode determinar se

dados corretos em uma auditoria. A isto se atribui rastreabilidade dos dados. O

teste caixa preta não demonstra como se obtiveram os dados, mas quais dados. No

teste de caixa preta, de nível mais alto, as unidades foram testadas e aprovadas, isto

significa que o processo de obtenção já não importa, mas os dados obtidos, de

entrada e de saída, sim.

Na Integração, não é recomendado que se faça o teste do tipo big-bang, em que

todos os componentes são integrados e depois testados. Caso se encontre alguma

falha de componente na integração, após a correção ou modificação, caso de

iteração, deve-se realizar o teste de regressão, em que se reexecutam os testes de

componentes para evitar a propagação de falhas ou efeitos colaterais.

No teste de Validação, a técnica de caixa preta é a única utilizada, pois devem ser

feitos diretamente com o usuário. Para tanto se rastreiam os requisitos do software

que sejam visíveis ao usuário. Neste ponto deve-se atentar especialmente ao valor,

o desempenho do software e suas funcionalidades, para que o usuário perceba a

utilidade de suas funcionalidades e a velocidade, tempo gasto, clics, sobrecarga do

sistema, da rede ou outras partes computacionais.

Na Validação a versão Alfa entrega um software pronto e se realizam os testes com

o usuário e o desenvolvedor. A versão Beta somente o usuário é quem testa.

O Teste de Sistema pertence ao Sistema de Informação da empresa. Isto significa

que o software deve ser combinado com outros sistemas e se os dados e o

desempenho global foram alcançados. O plano de recuperação pretende a proteção

do sistema da empresa, assim evita que os erros ultrapassem o sistema e atinja

outras partes. Ex.: Se o ERP de uma empresa falhar não poderá afetar o sistema de

produção CAD/CAM. A produção deverá continuar até que se reinicie o sistema.

O teste de Desempenho é importante para detectar até que ponto o sistema

suporta. Este teste deve ser feito até que não seja possível sua continuidade. Você

Page 28: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

25

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

pode combinar por comportamento, como um nº X de conexão simultâneas ou por

estresse com a inserção Y de registros. Você pode testar com um única caractere ou

um registro complexo com vários caracteres em vários campos. Há também o teste

que pode verificar o comportamento e o estresse, porém ele tende à caixa preta,

pois não permitirá a real verificação de qual dos dois testes interrompeu o sistema,

mas são bons para mensurações rápidas.

Page 29: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

26

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

CMMI

Framework de aprimoramento de processos

O Instituto de Engenharia de Software (SEI – Software Engeneering Institute

[http://www.sei.cmu.edu]) foi criado para aumentar a capacidade e a qualidade de

produção de software nos Estados Unidos. Este instituto desenvolveu métodos de

avaliação de fornecedores e capacitação de desenvolvedores. O resultado foi o

Modelo de Maturidade de Capacitação (CMM – Capability Maturity Model) do SEI.

Paralelamente a isto surgiram outros modelos como o P-CMM (People), o SPICE

(mais flexível para adaptação a um número maior de condições de diferentes

empresas) e o projeto Bootstrap, que utiliza o CMM como base e inclui o estudo do

processo de qualidade das empresas para aprimoramento do software, a distinção

clara ente Organização, Metodologia e Tecnologia e ainda, um modelo base de

processos.

Para unificar tantos novos modelos o SEI desenvolveu um modelo Integrado, o

CMMI, que passou a substituir os outros modelos do CMM, que de forma

simplificada pode ser resumido em:

Tabela 1 - Áreas de processo do CMMI

Categoria Área de processo

Gerenciamento de processo Definição dos processos organizacionais

Foco de desenvolvimento no processo

Treinamento organizacional

Desempenho (mensurável)de processo

Inovação e implantação

Gerenciamento de projeto Planejamento de projeto

Monitoração e controle de projeto

Gerenciamento por fornecedor

Gerenciamento de projeto integrado

Gerenciamento de riscos

Page 30: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

27

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Integração de equipes

Gerenciamento quantitativo de projeto

Engenharia Gerenciamento de requisitos

Desenvolvimento de requisitos

Solução técnica

Integração de produto

Verificação

Validação

Apoio Gerenciamento de configuração

Gerenciamento de qualidade de

processo e de produto

Medição e análise

Análise de decisão e resolução

Ambiente organizacional para

integração

Análise causal e resolução

O CMMI descreve de forma detalhada as 24 Áreas De Processo principais ou

relevantes para a capacitação, declarando seus Objetivos, que são descrições

abstratas do estado que se deseja atingir com determinado processo e as Práticas

que são os métodos para atingir os objetivos.

Page 31: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

28

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Figura 4 - Modelo CMMI

O modelo CMMI é dividido em 6 estágios.

Page 32: Engenharia de Sistemas IV - institutosiegen.com.brinstitutosiegen.com.br/documentos/euhl.13545531545250.pdf · Prof. Erwin Alexander Uhlmann –  Sumário Introdução

29

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Bibliografia

HOGAN, Brian P. Web Design para Desenvolvedores. Rio de Janeiro. Editora Ciência

Moderna, 2011.Pressman, Roger S. Engenharia Web. Rio de Janeiro. LTC, 2009.

PRESSMAN, Roger S. Engenharia Web. Rio de Janeiro. LTC, 2009.

CYBIS, Walter. Ergonomia e Usabilidade: conhecimentos, métodos e aplicações. São

Paulo. Novatec, 2007.

SILVA, Maurício Samy. Construindo sites com CSS e (X)HTML: sites controlados por

folhas de estilo em cascata. São Paulo. Novatec, 2008.

POWERS, Shelley. Aprendendo JavaScript. São Paulo. Novatec, 2010.

SILVA, Maurício Samy. Criando sites com HTML: sites de alta qualidade com HMTL e

CSS. São Paulo. Novatec, 2008.