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.
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.
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.
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
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
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!
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?
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.
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?
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.
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?
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.
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.)
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
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
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
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
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
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.
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;
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):
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;
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
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.
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.
22
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
Figura 3 - Baseado em componentes
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.
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ê
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.
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
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.
28
Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br
Figura 4 - Modelo CMMI
O modelo CMMI é dividido em 6 estágios.
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.