engenharia de Software - Projeto de Software

Prévia do material em texto

Paulo Enoque 
Engenharia de Software/Modelagem de Sistemas
Tópicos
	Introdução a Teoria Geral dos Sistemas
	Engenharia de Software
	Análise de Sistemas
	O que é software?
	Componentes de uma equipe de desenvolvimento.
	Metodologias de Desenvolvimento
	UML
Tópicos
	Orientação da Objetos: Narração, descriminação e dissertação
	Padrões de Projetos de Software
Introdução à Teoria Geral de Sistemas
	Um ERP de uma empresa pode se comunicar com os sistemas de seus fornecedores (podemos dizer que temos um sistema aberto) ou não (as informações estão restritas ao próprio sistema). 
Via Láctea tipo do sistema
natural
Introdução à Teoria Geral de Sistemas
Sistema Nervoso de outro
tipo de sistema natural
Introdução à Teoria Geral de Sistemas
Sistema de ERP
ERP (Enterprise
Resource Planning): Esse termo, que pode ter traduzido como sistema integrado de gestão empresarial, é um sistema de informação que integra todos os dados e processos de uma organização.
Engenharia de Software
	Atualmente, quase todos os países dependem de sistemas baseados em computadores, não somente os governos, mas as sociedades civis como um todo. Nesse contexto complexo, em que uma falha pode acarretar situações desagradáveis, a produção e a manutenção de softwares de forma adequada são essenciais no mundo globalizado do século XXI.
Engenharia de Software
O conceito de engenharia de software foi apresentado pela primeira vez no ano de 1968, quando a indústria passava pelo que foi denominado ‘‘crise do software”. Essa crise ocorreu com a introdução de circuitos integrados nos computadores da época, de modo que o poder de processamento do hardware aumentou consideravelmente. 
Engenharia de Software
Assim, o ambiente desafiador desse período tornou possível o desenvolvimento de novas técnicas e especificações que pudessem lidar com a complexidade dos novos sistemas construídos.
Essas técnicas tornaram-se parte da engenharia de software e são amplamente empregadas até os dias atuais.
Análise de sistemas
	Esse conceito era tratado como uma abordagem para resolver os problemas de decisão, isto é, problemas que apresentavam algum estado de dúvida, sendo que as alternativas de solução devem ser estudadas visando à melhor solução para determinada situação.
Análise de sistemas
	Quando usamos a palavra análise, podemos explicar esse termo de uma forma bem simplificada: consiste em automatizar decisões de forma que um programa siga determinado fluxo, conforme informações imputadas para esse fim.
Análise de sistemas
Análise de sistemas
Bem, na análise também é possível propor modelos de solução (protótipos) de um sistema, de forma a se chegar à solução objetiva.
O que é Software
	o termo software (programa) ao conjunto de instruções realizadas por um desenvolvedor, compiladas em uma linguagem de programação e executadas em um computador.
O que é Software
	Software não é apenas o programa, mas todos os dados de documentação e configuração associados, necessários para que o programa opere corretamente
O que é Software
Os softwares podem ser classificados em categorias. Há duas classificações simples em que um software poderia ser encaixar. A primeira, como um produto genérico, em que se encaixam editores de texto, pacotes gráficos etc.; 
O que é Software
E a segunda, como um produto feito sob encomenda, ou personalizado, como um sistema feito para determinado cliente. Além disso, podemos ter programas feitos para usos específicos, como softwares embarcados ou softwares embutidos. Isso sem contar as classificações para softwares livres.
Equipe de Desenvolvimento
	Além de técnicas para desenvolvimento de software, existe um fator-chave que pode garantir ou não o sucesso de um projeto: o fator humano.
Equipe de Desenvolvimento
	A quantidade de pessoas em uma equipe também pode variar, bem como o cargo que elas ocupam.
Equipe de Desenvolvimento
Gerente de projeto: profissional responsável pela gerência e coordenação das atividades necessárias à construção do sistema.
Analista: é o profissional que deve ter conhecimento do domínio do negócio. Tipicamente, é o analista que faz a ponte entre as necessidades do cliente e as especificações técnicas.
Equipe de Desenvolvimento
Projetistas: o projetista é um componente da equipe de desenvolvimento que não tem uma função predefinida. Ele pode cuidar desde o projeto de interface (tela, cores etc.) até as alternativas de soluções de problemas resultantes da análise.
Equipe de Desenvolvimento
Arquiteto de software: como o nome diz, ele é o arquiteto do sistema. Geralmente esse tipo de profissional é encontrado em grandes equipes e responde pela especificação do sistema. Por exemplo, define se ele rodará na web e em sistemas desktop.
Equipe de Desenvolvimento
Programador: é o profissional que responde pela implementação (codificação) do sistema. É o profissional mais comum de se encontrar em uma equipe de desenvolvimento junto com o analista.
Equipe de Desenvolvimento
Cliente: um dos componentes-chave de um projeto de software, ele é o indivíduo ou um grupo de indivíduos para qual o sistema é destinado.
O cliente também pode ser classificado em duas categorias: cliente usuário, que utilizará o sistema, e cliente contratante, que é quem solicitou o sistema.
Equipe de Desenvolvimento
Avaliadores de qualidade: desempenho e confiabilidade são dois pontos que um software deve oferecer. Os avaliadores de qualidade são profissionais que verificam a adequação do software às normas de qualidade da empresa.
Metodologias de Desenvolvimento de Sistemas
	Existem vários modelos e estruturas para desenvolver um sistema. Uma das primeiras metodologias a aparecer foi o modelo denominado cascata.
Metodologias de Desenvolvimento de Sistemas
	A adoção dessa abordagem pode ser considerada arriscada nos dias atuais se for escolhida como metodologia para construção de um novo sistema. Se no projeto do software ocorresse uma eventual mudança de escopo, isso quebraria a proposta do modelo, sendo que o ciclo anterior só poderia ser retomado na finalização da última etapa e o ciclo começaria novamente.
Metodologias de Desenvolvimento de Sistemas
	Apesar de eventuais restrições, esse modelo clássico pode ser adotado em determinados tipos de projetos que não demandem alterações de escopo e que as fases são sequenciais, como um software embarcado para determinado hardware.
Metodologias de Desenvolvimento de Sistemas
As fases de desenvolvimento:
	Levantamento de requisitos: essa atividade é a etapa de compreensão do problema aplicado ao desenvolvimento de software. O principal objetivo dessa etapa é que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido.
Metodologias de Desenvolvimento de Sistemas
As fases de desenvolvimento:
Análise de requisitos: essa etapa consiste em “quebrar” um sistema em seus componentes e estudar como eles interagem, com o objetivo de entender como esse sistema funciona.
Metodologias de Desenvolvimento de Sistemas
As fases de desenvolvimento:
	Projeto: nessa etapa da construção do sistema é determinado ‘‘como’’ o sistema funcionará para atender os requisitos, de acordo com os recursos tecnológicos existentes.
	Implementação: aqui o sistema é codificado, ou seja, construído. Dessa forma, ocorre a tradução da especificação da fase de projeto em código executável pelo uso de uma ou mais linguagens de programação.
Metodologias de Desenvolvimento de Sistemas
	As fases de desenvolvimento:
	Testes: etapa que valida e verifica se o sistema construído atende as especificações levantadas e se ele apresenta falhas (erros).
	Implantação: etapa em que o sistema é ‘‘empacotado’’, distribuído e instalado no ambiente do usuário.
Metodologias de Desenvolvimento de Sistemas
Metodologias de Desenvolvimento de Sistemas
Pesquise sobre a metodologia de Desenvolvimento de Software XP e Scrum. Verifique os pontos forte e fracos dessas metodologias.
 
Metodologias de Desenvolvimento de Sistemas
	Tambémpodem existir variações desse modelo. Por exemplo, o projeto pode andar em paralelo com a implementação, contudo, as variações não representam o modelo original.
Metodologias de Desenvolvimento de Sistemas – Iterativo Incremental
Esse modelo foi proposto como uma possível alternativa aos problemas encontrados no modelo cascata.
Um produto de software que siga essa metodologia divide o desenvolvimento em ciclos. Cada ciclo contém as fases de análise, projeto, implementação e testes.
*
Metodologias de Desenvolvimento de Sistemas – Iterativo Incremental
Metodologias de Desenvolvimento de Sistemas – Metodologias ágeis
As metodologias ágeis são adequadas para situações em que existem muitas mudanças de requisitos.
Cada metodologia ágil tem suas características, porém, todas têm o foco na entrega de algo funcional por ciclo de software, em vez de, por exemplo, escrever uma documentação excessiva sobre o funcionamento do sistema.
Metodologias de Desenvolvimento de Sistemas – Metodologias ágeis
	As metodologias ágeis mais conhecidas são Extreme Programming e Scrum.
Metodologias de Desenvolvimento de Sistemas – Metodologias ágeis
A metodologia Extreme Programming (XP), pode-se dizer que é uma metodologia voltada para equipes pequenas e médias, que desenvolvem software baseado em macrorequisitos e que são modificados rapidamente.
Metodologias de Desenvolvimento de Sistemas – Metodologias ágeis
Porém ,o que difere realmente a XP de outras
metodologias é:
	 feedback constante;
	abordagem incremental;
	estímulo à comunicação entre as pessoas.
Metodologias de Desenvolvimento de Sistemas – Metodologias ágeis
	Já quanto ao Scrum, seu objetivo é fornecer um processo conveniente para projeto e desenvolvimento orientado a objetos. Essa metodologia tem como foco o trabalho flexível e que se adapte a ambientes muito dinâmicos, que trata, além de aspectos de alteração de projeto com mudança de requisitos, da troca de equipes, adaptações de cronogramas e orçamentos etc.
O que é um software de qualidade?
O software que satisfaz os requisitos solicitados pelo usuário. Deve ser fácil de manter, ter boa performance, ser confiável e fácil de usar
Alguns atributos de qualidade
Manutenabilidade
O software deve evoluir para atender os requisitos que mudam
O que é um software de qualidade?
Eficiência
O software não deve desperdiçar os recursos do sistema
Usabilidade
O software deve ser fácil de usar pelos usuários para os quais ele foi projetado
Qualidade de Software 
(um exemplo para o Varejo)
Correto
A loja não pode deixar de cobrar por produtos comprados pelo consumidor
Robusto e altamente disponível
A loja não pode parar de vender
Qualidade de Software 
(um exemplo para o Varejo)
Eficiente
O consumidor não pode esperar
A empresa quer investir pouco em recursos computacionais (CPU, memória, rede)
Qualidade de Software 
(um exemplo para o Varejo)
Amigável e fácil de usar 
A empresa quer investir pouco em treinamento
Altamente extensível e adaptável
A empresa tem sempre novos requisitos (para ontem!)
Qualidade de Software 
(um exemplo para o Varejo)
A empresa quer o software customizado do seu jeito (interface, teclado, idioma, moeda, etc.)
Reusável
Várias empresas precisam usar partes de um mesmo sistema
Qualidade de Software 
(um exemplo para o Varejo)
Aberto, compatível, de fácil integração com outros sistemas
A empresa já tem controle de estoque, fidelização, etc. 
Portável e independente de plataforma (hw e sw)
A empresa opta por uma determinada plataforma
Baixo custo de instalação e atualização
A empresa tem um grande número de PDVs
Produtividade
Custo de desenvolvimento reduzido
A empresa consumidora quer investir pouco em software
A empresa produtora tem que oferecer “software barato” 
Tempo de desenvolvimento reduzido 
Suporte rápido às necessidades do mercado 
“Software Barato”
Nem tanto resultado de baixos custos de desenvolvimento, mas principalmente da distribuição dos custos entre vários clientes.
Reuso, extensibilidade e adaptabilidade são essenciais para viabilizar tal distribuição.
Importância da Engenharia de Software
Qualidade de software e produtividade garantem:
Disponibilidade de serviços essenciais 
Segurança de pessoas
Competitividade das empresas
Produtores
Consumidores
Mas, na realidade, temos a Crise de Software...
25% dos projetos são cancelados
o tempo de desenvolvimento é bem maior do que o estimado
75% dos sistemas não funcionam como planejado
Mas, na realidade, temos a Crise de Software...
a manutenção e reutilização são difíceis e custosas
os problemas são proporcionais a complexidade dos sistemas
Causas da Crise de Software
Essências
Complexidade dos sistemas 
Dificuldade de formalização
Acidentes
Má qualidade dos métodos, linguagens, ferramentas, processos, e modelos de ciclo de vida
Falta de qualificação técnica
Elementos e Atividades da Engenharia de Software
Elementos
Modelos do ciclo de vida do software 
Linguagens
Métodos
Ferramentas
Processos 
Atividades
Modelagem do negócio
Licitação de requisitos
Análise e Projeto
Implementação
Testes
Distribuição
Planejamento 
Gerenciamento
Gerência de Configuração e Mudanças
Manutenção
O que é um modelo de ciclo de vida de processo de software?
Uma representação abstrata e simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de software
O processo de Desenvolvimento
de Software
	Projetos que terminam dentro do prazo estimado: 10%
	 Projetos que são descontinuados antes de chegarem ao fim: 25%
	 Projetos acima do custo esperado: 60%
	 Atraso médio dos projetos: um ano
Atividades Típicas
	Compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software.
Levantamento de Requisitos
	Compreensão do problema.
	Levar a usuários e desenvolvedores a mesma
 visão.
	Desenvolvedores juntamente com clientes tentam levantar e definir as necessidades dos usuários.
Levantamento de Requisitos
São condições ou capacidades que devem ser alcançadas ou possuídas por um sistema ou componente para satisfazer um contrato, padrão, especificação ou outros documentos
formalmente impostos.
Levantamento de Requisitos – Requisitos Funcionais
	Requisitos Funcionais: definem as funcionalidades do sistema.
Levantamento de Requisitos – Requisitos Não - Funcionais
	Requisitos Não-Funcionais: declaram as características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades.
Levantamento de Requisitos – Requisitos Funcionais
a. O sistema deve permitir que cada professor realize o lançamento de notas das turmas que lecionou.
b. O sistema deve permitir que o aluno realize sua matrícula nas disciplinas oferecidas em semestre letivo.
Levantamento de Requisitos – Requisitos Funcionais
	c. Os coordenadores da escola devem poder obter o número de aprovações, reprovações e trancamentos em cada disciplina oferecida em um determinado período.
Levantamento de Requisitos – Requisitos Não- Funcionais
a. Confiabilidade: medidas dos níveis de confiança, tais como tempo médio entre falhas, recuperação de falhas, quantidade de erros por linhas cód. fonte.
b. Desempenho: tempo de resposta esperado para funcionalidades do sistema
Levantamento de Requisitos – Requisitos Não- Funcionais
c. Portabilidade: restrições sobre hardware e software nas quais o sistema será implantado.
d. Segurança: limitações em relação a acessos não autorizados.
e. Usabilidade: por exemplo, requisitos sobre facilidade de uso e necessidade ou não de treinamento dos usuários.
Levantamento de Requisitos – Requisitos Normativos:
Declaração de restrições impostas sobre o desenvolvimento do sistema.
Restrições também podem corresponder a regras do negócio, restrições ou políticas de funcionamento específicas do domínio do problema.
Levantamento de Requisitos – Requisitos Normativos:
Os requisitos devem ser expressos de uma maneira tal queeles possam ser verificados e comunicados a leitores técnicos e não-técnicos.
Documento de Requisitos
Não deve conter informações sobre soluções
técnicas a serem adotadas.
Deve responder a questão “o que o usuário
necessita do novo sistema?”
Documento de Requisitos
Requisitos definem o problema a ser resolvido pelo sistema de software.
Eles não descrevem o software que resolve o
problema.
Documento de Requisitos
Constitui a base para as atividades subsequentes do desenvolvimento do sistema.
Estabelece o escopo do sistema: o que faz parte e o que não faz parte do sistema.
Documento de Requisitos
Tem como característica a volatilidade.
“Um requisito volátil é aquele que pode sofrer modificações durante o desenvolvimento
do sistema”.
Documento de Requisitos
O ponto principal do levantamento de requisitos é compreender o sistema o máximo possível antes de começar a construí-lo.
Define-se qualquer requisito já conhecido.
Documento de Requisitos
 A medida que novos requisitos sejam detectados ( ou sofram mudanças) deve se analisar o impacto das mudanças no escopo do sistema.
Fases do Levantamento de
Requisitos
Análise:
O termo análise corresponde a “quebrar” um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona.
Fases do Levantamento de
Requisitos
Analistas realizam um estudo detalhado dos
requisitos.
A partir desse são construídos os modelos para representar o sistema a ser construído.
Fases do Levantamento de
Requisitos
Analistas realizam um estudo detalhado dos
requisitos.
A partir desse são construídos os modelos para representar o sistema a ser construído.
Fases do Levantamento de
Requisitos
	Buscar a melhor solução para o problema sem se preocupar com os detalhes da tecnologia a ser utilizada.
Fases do Levantamento de
Requisitos
	Validação:
Assegurar que as necessidades do cliente estão sendo atendidas pelo sistema.
Apresentação dos modelos criados aos futuros usuários para que esses modelos sejam validados.
Fases do Levantamento de
Requisitos
	Verificação:
Analisa se os modelos construídos estão em conformidades com os requisitos definidos.
Analisa se o software está sendo construído corretamente.
Análise do Domínio
Identifica e modela os objetos do mundo real que, de alguma forma, serão processados pela aplicação em desenvolvimento.
Identifica as regras do negócio e os processos do
negócio realizados pela organização. Temos o
analista de domínio. Ex: Sistema Acadêmico -> objeto “Aluno”.
	Aluno é um objeto do domínio.
Análise da Aplicação
Identifica objetos de análise que normalmente não fazem sentido para os especialistas de domínio, mas que são necessários para suprir as funcionalidades do sistema.
Envolve apenas a identificação dos objetos, não envolvendo o detalhamento.
Ex: tela de cadastro dos alunos
Projeto (desenho)
	Determina como o sistema funcionará para atender aos requisitos, de acordo com os recursos tecnológicos existentes.
	Aos modelos construídos na análise são denominadas “restrições de tecnologia”.
	Ex: arquitetura do sistema, padrão de interface gráfica, linguagem de programação, gerenciador de banco de dados, etc.
Projeto (desenho)
Determina como o sistema funcionará para atender aos requisitos, de acordo com os recursos tecnológicos existentes.
Aos modelos construídos na análise são denominadas “restrições de tecnologia”.
Modelos Iterativos
Requisitos de sistema SEMPRE evoluem durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas
Modelos Iterativos
Iterações podem ser aplicadas a quaisquer dos modelos de ciclo de vida 
Duas abordagens (relacionadas)
Desenvolvimento espiral 
Desenvolvimento incremental
Desenvolvimento Espiral
Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. 
análise de riscos em intervalos regulares do processo de desenvolvimento de software
planejamento
controle
tomada de decisão
Desenvolvimento Espiral
O processo é representado como uma espiral em vez de uma sequência de atividades
Cada volta na espiral representa uma fase no processo
Não há fases fixas como especificação ou projeto - voltas na espiral são escolhidas dependendo do que é requerido
Riscos são avaliados explicitamente e resolvidos ao longo do processo
Linguagem
Notação com sintaxe e semântica bem definidas
com representação gráfica ou textual 
Usada para descrever os artefatos gerados durante o desenvolvimento de software 
Exemplos: UML, Java
Ferramenta CASE
Provê suporte computacional a um determinado método ou linguagem
Ambiente de desenvolvimento: conjunto de ferramentas integradas (CASE)
Exemplos: Rational Rose, JBuilder
Processo
Conjunto de atividades 
bem definidas 
com responsáveis
com artefatos de entrada e saída
com dependências entre as mesmas e ordem de execução
com modelo de ciclo de vida
Processo de software
Um conjunto de atividades cujo objetivo é o desenvolvimento ou a evolução do software
Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software
Metodologia
Conjunto de métodos + processo
Pontos principais
Engenharia de software é uma disciplina de engenharia que está envolvida com todos os aspectos da produção de software
Produtos de software consistem de programas desenvolvidos e documentação associada. Alguns atributos de qualidade do produto são manutenabilidade, eficiência e usabilidade
O processo de software consiste nas atividades que são envolvidas no desenvolvimento de produtos de software
Pontos principais
Métodos são formas organizadas de produzir software. Eles incluem sugestões para o processo a ser seguido, as notações a serem usadas, regras que governam as descrições do sistema que são produzidas e diretrizes de projeto
Pontos principais
Ferramentas CASE são sistemas de software que são projetados para suportar as atividades rotineiras no processo de software, como edição de diagramas de projeto e verificação de consistência dos diagramas
UML
	A Unified Modeling Language (UML), ou Linguagem de Modelagem Unificada, foi originada a partir do trabalho de várias pessoas durante a década de 1990.
UML
	Por ser uma linguagem visual, a UML é constituída de vários elementos gráficos que permitem construir diagramas para representar as várias visões de um sistema. 
UML
	Assim, para construir os diagramas, cada elemento gráfico tem uma gramática (sintaxe ou forma definida predeterminada para desenhar o elemento) e uma semântica que define o significado do elemento e para que ele deve ser utilizado.
UML
	cinco perspectivas ou visões;
	distintas, onde cada visão aborda um aspecto do sistema.
	transcritas da especificação da UML, são as seguintes:
UML
Visão de projeto: enfatiza as características do sistema que dão suporte tanto estrutural como comportamental a ele. Representa as funcionalidades externas e visíveis do sistema.
Visão de casos de uso: descreve um sistema a partir de um ponto de vista externo, demonstrando um conjunto de interações entre o sistema e os agentes externos a este.
UML
Visão de processo: essa visão mapeia as características de concorrência (paralelismo), sincronização e desempenho do sistema.
Visão de implementação: abrange o gerenciamento de versões do sistema, construída pelo agrupamento de suas partes (componentes e subsistemas).
UML
	Visão de implantação: corresponde à distribuição física do sistema em seus subsistemas e à conexão entre essas partes.
UML - Atores
	Dentro da UML, um ator representa um conjunto de papéis que os usuários de casos de uso desempenham quando interagem com esses casos de uso. Tipicamente, Após conhecer os representantes do ator, vamos aos casos de uso.
UML – Casos de Uso
	Por exemplo, a compra de entrada para o cinema via internet por uma pessoa envolve o ator cliente (pessoa), que compra o ingresso e interage com a funcionalidade de vendas de ingresso, que é uma parte do sistema de controlede cinemas. Caso o cliente compre o ingresso diretamente na bilheteria do cinema, o mesmo caso de uso (venda de ingresso) deve atender a um segundo ator, nesse caso o atendente.
UML – Casos de Uso
UML – Diagrama de Classes
	Quando se está especificando um sistema, ele é planejado para atender alguma necessidade. Partindo da ideia de que uma necessidade tem requisitos que precisam ser observados, um dos primeiros passos para se entender o problema é construir o diagrama de classes.
UML – Diagrama de Classes
A primeira etapa para começar a construção do diagrama após ter em mãos as informações iniciais é descobrir as próprias classes que compõem o diagrama e suas associações, já que estas fornecem uma abordagem geral do problema
UML – Diagrama de Classes
	Feito esse levantamento inicial, crie os possíveis atributos das classes ou atributos que possam identificar as associações entre as classes. Em seguida, tente descobrir possíveis relações de herança entre elas.
UML – Diagrama de Classes
Os passos descritos aqui podem ser resumidos da seguinte forma:
	Descobrir as classes que compõem o problema.
	Preparar um dicionário de dados que contenha as informações de cada classe, como escopo, restrição de uso etc.
	Encontrar as possíveis associações entre as classes.
UML – Diagrama de Classes
	Identificar atributos dos objetos e possíveis ligações.
	Simplificar as classes utilizando as operações de herança/generalização.
	 Verificar se a associação entre as classes do seu modelo permite que suas consultas retornem o que você espera, como um valor único ou múltiplos valores.
UML – Diagrama de Classes
	Analisar, refinar, interagir no seu modelo.
	Repensar o nível de abstração.
	Agrupar as classes em pacotes, visto que um pacote nada mais é do que um conjunto de classes com um propósito comum.
UML – Diagrama de Classes
Modelos - Sistemas
	Representação esquemática de um modelo de sistema
Modelo de Simulação
Sistema do Mundo Real
Entradas
(Dados)
Saídas
(Respostas)
Experimentação
Processo - 
	Conjunto de atividades 
	bem definidas 
	com responsáveis
	com artefatos de entrada e saída
	com dependências entre as mesmas e ordem de execução
	com modelo de ciclo de vida
Processo de software
	Um conjunto de atividades cujo objetivo é o desenvolvimento ou a evolução do software
	Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software
Pontos principais
	Engenharia de software é uma disciplina de engenharia que está envolvida com todos os aspectos da produção de software
	Produtos de software consistem de programas desenvolvidos e documentação associada. Alguns atributos de qualidade do produto são manutenabilidade, eficiência e usabilidade
	O processo de software consiste nas atividades que são envolvidas no desenvolvimento de produtos de software
Pontos principais
	Métodos são formas organizadas de produzir software. Eles incluem sugestões para o processo a ser seguido, as notações a serem usadas, regras que governam as descrições do sistema que são produzidas e diretrizes de projeto
	Ferramentas CASE são sistemas de software que são projetados para suportar as atividades rotineiras no processo de software, como edição de diagramas de projeto e verificação de consistência dos diagramas
Desenvolvimento Incremental
	Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida
	Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais
	Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores
Mas, na realidade, temos a Crise de Software...
	25% dos projetos são cancelados
	o tempo de desenvolvimento é bem maior do que o estimado
	75% dos sistemas não funcionam como planejado
	a manutenção e reutilização são difíceis e custosas
	os problemas são proporcionais a complexidade dos sistemas
*
Mitos...
	da Gerência...
 Manuais de Regras 
e Procedimentos
 Ferramentas modernas
de software e hardware 
são suficientes
 Estamos atrasados… 
Vamos alocar 
mais gente ao projeto!
Desatualizados, obsoletos
O uso eficiente de ferramental exige conhecimento
Custos de treinamento, gerência e entendimento do processo de trabalho
*
*
Mitos...
	do Desenvolvedor/Programador...
 Programa escrito 
e testado! 
Acabei!
 Até que o programa 
esteja “rodando” não
há como medir 
sua qualidade
O único produto de um
 projeto de software é o 
conjunto de programas
Quanto mais cedo voce escrever o código, mais tempo irá demorar para completá-lo
De 50 a 70 % do custo de produção de um software vai ser gasto para operacionalizá-lo para o usuário
Revisões anteriores à codificação
Especificação, projeto, plano de trabalho
*
*
Mitos...
	do Cliente...
Uma lista de intenções (boas) 
é suficiente para começar 
a produzir o software
Minhas necessidades vão mudar… 
Mas mudanças são fáceis de introduzir 
porque software é bastante flexível
Custo de mudanças é muito alto
A Especificação do Software é a fase mais crítica do processo
Erros na fase inicial têm um custo muito alto de correção
*
*
O que é Engenharia de Software?
Estudo e aplicação de Métodos e Técnicas com o objetivo de tornar o desenvolvimento de software mais “eficiente”.
“O estabelecimento e uso de princípios de engenharia de forma a obter economicamente software confiável e que funcione eficientemente em máquinas reais.”
*
*
Engenharia de Software
	Existe como disciplina há pouco tempo
	Estabelece um diferencial entre um engenheiro de software profissional e um “praticante da informática”
	Novos profissionais são agentes de mudanças ou de problemas
	oportunidades, desafios e perigos
*
*
Engenharia de Software
	Produtividade	
	linhas de código por dia; 
	pontos de função por mês
	Qualidade	
	confiabilidade (e.g.: defeitos por KLOC); e
	manutenibilidade (manutenção fácil).
*
*
Princípios da Engenharia
	MÉTODOS
	FERRAMENTAS 
	PROCEDIMENTOS
*
*
Métodos
	Instrumentos
	representação do software durante seu desenvolvimento
	Notações
	Linguagens
	Critérios de Qualidade
	Como avaliar o desenvolvimento 
	Exemplos
	UML
	Booch
	Análise estruturada
	Anlaise Essencial
Como construir o Software?
*
*
Ferramentas
	Suporte automático ou semi-automático aos métodos
	CASE - Computer Aided Software Engineering
	Ambientes de desenvolvimento
	ferramentas integradas
	Hardware + Software (de suporte) + Banco de Dados
É preciso muito software para desenvolver software!
*
*
Procedimentos
	Seqüência dos métodos
	sequência de passos e atividades
	Resultados 
	documentos, relatórios, módulos
	Controles 
	coordenação, critérios de qualidade, pontos de controle
	Equipe
Quais os passos para construir o software?
*
*
Software
Produto
Processo
Software
*
Software deve ser visto não só como o produto final gerado como também como o processo que foi utilizado para sua construção. Ou seja, a forma como se realiza o processo de desenvolvimento (quais métodos, quais instrumentos e quais atividades foram realizadas) influencia a qualidade do produto final. Da mesma forma, dependendo das características do produto que se quer gerar, deve-se escolher um processo adequado para sua construção.
*
Produto de Software
Plano
Especificação
Projeto
Testes e Validações
Programa Fonte
Programa
Objeto
Estrutura de Dados
*
Um software é mais do que seu código fonte. Ele compreende os diversos documentos ou representações que são criadas ao longo do seu processo de desenvolvimento.
*
Processo de Construção de Software
Equipe
Ferramentas
Métodos
Passos/Atividades
ProdutosInstrumentos
Processo
*
Durante um processo de desenvolvimento, métodos e instrumentos são utilizados para se construir os diversos produtos. Estes métodos, na maioria dos casos, exigem a utilização de ferramentas para sua realização. Estas ferramentas serão utilizadas pelos membros da equipe escalada para desenvolver o sistema.
*
Ciclo de Vida de Software
Definição dos requisitos
Análise
Projeto
Implementação
Teste/Avaliação
Implantação
Manutenção
Documentos são gerados
a cada fase e servem de
entrada para a fase seguinte
*
*
Ciclo de Vida - Modelo Cascata
Intenções
Especificação do Software
Projeto
do
Software
Código
do
Software
Sistema
pronto
para operar
Análise
Projeto
Implementação
Teste
Requisitos
do
Software
Definição de Requisitos
Documentos gerados
durante o ciclo de vida
Transformações
*
*
Definição de Requisitos
	Identificar
	desejos, intenções, procedimentos atuais e dados;
	Organizá-los de forma coerente
	Definir de uma forma geral
	o que será tratado pelo software
	interface com o que fica de fora do software
Desejos
Intenções
Procedimentos
Dados
Requisitos
do
Software
*
*
Análise do Software
	Entendimento e Representação
	Domínio do problema
	Conceitos
	Funcionalidades 
	Casos de uso
	Baseado nos fatores críticos de sucesso do software
	
Especificação
do
Software
Requisitos
do
Software
*
*
Projeto do Software
	Projetar o Software
	Arquitetura
	Interfaces
	Estrutura de Dados
	Procedimentos
	Independente da Tecnologia onde será “encarnado” o software
Especificação
do
Software
Arquitetura
Interfaces
Estrutura
de
Dados
Detalhes
dos
Procedimentos
Projeto
do
Software
*
*
Construção do Código
	Implementação
	Programação do código
	Tecnologia
	linguagem
	ambiente
	etc
Arquitetura
Interfaces
Estrutura
de
Dados
Detalhes
dos
Procedimentos
Projeto
do
Software
Código
Software
*
*
Testes
	Estou construindo um sistema correto?
	Estou construindo o sistema certo?
	Teste de código
	Teste de sistema
	Testes com usuários
*
O teste de código tem o objetivo de verificar se um programa ou conjunto de programas não apresenta erros de execução.
Teste de sistema significa verificar se o sistemas dá as respostas desejadas de acordo com cada solicitação do usuário.
Testes com usuários são realizados com o objetivo de testar a interface do sistema e se todas as funcionalidades solicitadas foram contempladas pelo sistema.
*
Implantação do Software
	Pôr o Software em operação
	Entrada de dados
	Conversões de dados
	Treinamento de operadores
	Disponibilização de Manuais
	Suporte à operação
	Help Desk
	Acompanhar
Software
Software
Dados
Conversões
Pronto para operar
*
*
Manutenção do Software
	Manutenção
	Tipos
	Corretiva
	Novos Requisitos
	Novas Tecnologias 	
	Alto Custo
	Podem requerer mudanças nas fases iniciais do desenvolvimento
Software
Em Operação
Erros
Software
Nova Versão
Requisitos
*
*
Análise e Projeto OO
	Motivação e benefícios
	Enfrentar novos domínios de aplicação
	Melhorar a interação entre analistas e especialistas de domínios de aplicação
	Proporcionar uma representação básica consistente entre análise e projeto
	Reutilização
*
O que impulsionou uma proposta OO	
	Amadurecimento dos conceitos de orientação a objetos
	Aumento da complexidade de sistemas
	Maiores
	Sujeitos a alterações constantes
	Interativos
	Voltados para os usuários
Software: Mitos e Realidade
	É possível apontar, como causas principais dos problemas levantados na seção anterior, três principais pontos:
Software: Mitos e Realidade
	a falta de experiência dos profissionais na condução de projetos de software;
	a falta de treinamento no que diz respeito ao uso de técnicas e métodos formais para o desenvolvimento de software;
Software: Mitos e Realidade
	a “cultura de programação” que ainda é difundida e facilmente aceita por
	estudantes e profissionais de Ciências da Computação;
Software: Mitos e Realidade
	 a incrível "resistência" às mudanças (particularmente, no que diz respeito ao uso
	de novas técnicas de desenvolvimento de software) que os profissionais normalmente apresentam.
Mitos de Gerenciamento
	Mito 1. "Se a equipe dispõe de um manual repleto de padrões e procedimentos de desenvolvimento de software, então a equipe está apta a encaminhar bem o desenvolvimento."
Mitos de Gerenciamento
Realidade 1. Isto verdadeiramente não é o suficiente... é preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual... é necessário que o que conste
no dado manual reflita a moderna prática de desenvolvimento de software e que este seja
exaustivo com relação a todos os problemas de desenvolvimento que poderão aparecer no percurso...
Mitos de Gerenciamento
Mito 2. "A equipe tem ferramentas de desenvolvimento de software de última geração, uma vez que eles dispõem de computadores de última geração."
Mitos de Gerenciamento
Realidade 2. Ter à sua disposição o último modelo de computador (seja ele um mainframe, estação de trabalho ou PC) pode ser bastante confortável para o desenvolvedor do software, mas não oferece nenhuma garantia quanto à qualidade do software desenvolvido.
Mais importante do que ter um hardware de última geração é ter ferramentas para a automatização do desenvolvimento de software (as ferramentas CASE)...
Mitos do Cliente
	Mito 3 "Uma descrição breve e geral dos requisitos do software é o suficiente para iniciar o seu projeto... maiores detalhes podem ser definidos posteriormente."
Mitos do Cliente
	Realidade 3. Este é um dos problemas que podem conduzir um projeto ao fracasso, o cliente deve procurar definir o mais precisamente possível todos os requisitos importantes para o software: funções, desempenho, interfaces, restrições de projeto e critérios de validação são alguns dos pontos determinantes do sucesso de um projeto.
Mitos do Profissional
Mito 4. "Após a edição do programa e a sua colocação em funcionamento, o trabalho está
terminado."
Mitos do Profissional
	Realidade 4. O que ocorre na realidade é completamente diferente disto. Segundo dados obtidos a partir de experiências anteriores, 50 a 70% do esforço de desenvolvimento de um software é despendido após a sua entrega ao cliente (manutenção).
Mitos do Profissional
Mito 5. "Enquanto o programa não entrar em funcionamento, é impossível avaliar a sua
qualidade."
Mitos do Profissional
Realidade 5. Na realidade, a preocupação com a garantia do software deve fazer parte de todas as etapas do desenvolvimento, sendo que, ao fim de cada uma destas etapas, os documentos de projeto devem ser revisados observando critérios de qualidade.
Modelos de Desenvolvimento de software - O Modelo Queda d'Água
	Este é o modelo mais simples de desenvolvimento de software, estabelecendo uma ordenação linear no que diz respeito à realização das diferentes etapas.
Modelos de Desenvolvimento de software - O Modelo Queda d'Água
Modelos de Desenvolvimento de software - O Modelo Queda d'Água
O modelo Queda d'Água apresenta características interessantes, particularmente em razão da definição de um ordenamento linear das etapas de desenvolvimento.
Modelos de Desenvolvimento de software - O Modelo Queda d'Água
Primeiramente, como forma de identificar precisamente o fim de uma etapa de o início da seguinte, um mecanismo de certificação (ou revisão) é implementado ao final de cada
etapa
Modelos de Desenvolvimento de software - O Modelo Queda d'Água
isto é feito normalmente através da aplicação de algum método de validação ou verificação, cujo objetivo será garantir de que a saída de uma dada etapa é coerente com a sua entrada (a qual já é a saída da etapa precedente).
Prototipação
	O objetivo da Prototipação é um modelo de processo de desenvolvimento que busca contornar algumas das limitações existentes no modelo Queda d'Água. A ideia por trás deste modelo é eliminar a política de "congelamento" dos requisitos antes do projeto do sistema ou da codificação.
PrototipaçãoIsto é feito através da obtenção de um protótipo, com base no conhecimento dos requisitos iniciais para o sistema. 
Prototipação
	O desenvolvimento deste protótipo é feito obedecendo à realização das diferentes etapas já mencionadas, a saber, a análise de requisitos, o projeto, a codificação e os testes, sendo que não necessariamente estas etapas sejam realizadas de modo muito explícito ou formal.
Prototipação
	O desenvolvimento deste protótipo é feito obedecendo à realização das diferentes etapas já mencionadas, a saber, a análise de requisitos, o projeto, a codificação e os testes, sendo que não necessariamente estas etapas sejam realizadas de modo muito explícito ou formal.
Prototipação
Este protótipo pode ser oferecido ao cliente em diferentes formas, a saber:
	protótipo em papel ou modelo executável em PC retratando a interface homem-máquina capacitando o cliente a compreender a forma de interação com o software;
Prototipação
	um protótipo de trabalho que implemente um subconjunto dos requisitos indicados;
Prototipação
	um programa existente (pacote) que permita representar todas ou parte das funções desejadas para o software a construir.
Prototipação
	Colocado à disposição do cliente, o protótipo vai ajudá-lo a melhor compreender o que será o sistema desenvolvido. Além disso, através da manipulação deste protótipo, é possível validar ou reformular os requisitos para as etapas seguintes do sistema.
Prototipação – Características 
	é um modelo de desenvolvimento interessante para alguns sistemas de grande porte os quais representem um certo grau de dificuldade para exprimi r rigorosamente os requisitos;
Prototipação – Características 
	através da construção de um protótipo do sistema, é possível demonstrar a realizabilidade do mesmo;
Prototipação – Características 
	através da construção de um protótipo do sistema, é possível demonstrar a reutilizabiliadade do mesmo;
Prototipação – Características 
	é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial.
Prototipação – Características 
Prototipação
Os protótipos não são sistemas completos e deixam, normalmente, a desejar em alguns aspectos. Um destes aspectos é normalmente a interface com o usuário. 
Prototipação
Os esforços de desenvolvimento são concentrados principalmente nos algoritmos que implementem as principais funções associadas aos requisitos apresentados, a interface sendo, a este nível parte supérflua do desenvolvimento, o que permite caracterizar esta etapa por um custo relativamente baixo.
Prototipação
Por outro lado, a experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir certamente o seu custo, resultando também num sistema melhor concebido.
Entradas
(
Dados)
Modelo de
Simulação
Sistema do 
Mundo Real
Saídas
(
Respostas)
Experimentação