SlideShare uma empresa Scribd logo
1 de 15
Baixar para ler offline
ENGENHARIA DE SOFTWARE




                               Aula 02




   Prof. Cleuber Moreira Fernandes
   Mestre em Ciência da Computação - UnB
                   Cleubermf@yahoo.com.br
  http://br.groups.yahoo.com/group/ES-2008
1.      Engenharia de Software


1.1 Definição

Segundo Frits Bauer:

“É a criação e utilização de sólidos princípios de engenharia a fim de obter software de maneira
econômica, que seja confiável e que trabalhe eficientemente em máquinas reais.”

•    Não considera diretamente aspectos como:

     a) Qualidade – satisfação do cliente e pontualidade;

     b) Importância de métricas e de processo amadurecido.

•    Linha básica:

     a) Quais são os sólidos princípios?

     b) Equilíbrio economicidade e confiabilidade;

     c) Softwares eficientes em diferentes máquinas reais.



1.2 Processos, métodos e ferramentas

       Engenharia está sempre apoiada na gestão de qualidade total que leva a uma cultura de
processo contínuo de melhoria.

       O fundamento da engenharia de software é a camada de PROCESSO, que define uma estrutura
para um conjunto de áreas de processo – PA (Gestão Configuração, Gestão Requisitos, ...). Os
processos estabelecem quando, onde e como os métodos são aplicados para produzir os produtos de
trabalho (documentos, dados, relatórios), definem os marcos do projeto e gerenciam a qualidade.

        Os métodos fornecem as técnicas para construir software, com tarefas que abrangem análise de
requisitos, projeto, implementação, teste e implantação.
       Ferramentas consistem no apoio automatizado ou semi-automatizado para o processo e para os
métodos. A engenharia de software apoiada por computador – CASE combina software, hardware e
base de dados (informações sobre análise, projeto, teste, ...) para criar um ambiente de engenharia.


                                             Ferramentas

                                                Métodos
                                              Processos
                                           Foco na qualidade

                            Figura 01 – Camadas da Engenharia de Software
1.3 Abstração de Engenharia de Software

        Engenharia é a análise, projeto, construção verificação e gestão de elementos técnicos ou
sociais.

       Independente do produto ou solução, as seguintes perguntas precisam ser respondidas:

       a) Qual é o problema a ser resolvido?

       b) Que características do produto/solução são usadas para resolver o problema?

       c) Como os produtos serão construídos?

       d) Que abordagem será usada para descobrir erros cometidos no projeto e construção do
          produto?

       e) Como o produto será mantido a longo prazo, quando da necessidade de correções,
          adaptações e aperfeiçoamentos?

        O trabalho associado à engenharia de software pode ser realizado em três fases genéricas, cada
qual responde a uma ou mais das perguntas acima. Abaixo é apresentada uma combinação das
classificações dadas por Schwartz, Pressman e Sommerville:

1. Especificação ou Definição      O quê

Visa identificar: informação, função, desempenho, restrições de projeto e critérios de aceitação.

   • Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo
     questões extra-software;

   • Análise de Requisitos: levantamento das necessidades do software a ser implementado. A
     Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é
     um documento;
   • Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para
     verificar adequação.

2. Desenvolvimento      Como

        Como os dados devem ser estruturados, como a função deve ser implementada dentro da
arquitetura de software projetada para se alcançar o desempenho desejado, como as interfaces devem
ser caracterizadas, como o projeto deve ser traduzido numa linguagem de programação e como o teste
vai ser realizado.

2.1 Projeto

   • Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de
     módulos mais ou menos independentes;

   • Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida

   • Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para
     pseudo-código.
2.2 Implementação

   • Codificação: a implementação em si do sistema em uma linguagem de computador.

2.3 Validação

   • Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e
     comportamento adequado a nível das funções e módulos básicos do sistema;

   • Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a
     verificação da interação entre estes quando operando em conjunto.

3. Manutenção

        Foco nas modificações associadas com a correção de erros e adaptações à medida que o
ambiente do software evolui e os requisitos dos clientes se modificam. Esta fase aplica novamente os
conceitos das fases de Definição e Desenvolvimento, mas no contexto de software existente. Quatro
tipos de modificações são realizadas:

       1. Correção      manuteção corretiva – eliminação defeitos;

       2. Adaptação       mudanças no ambiente computacional, regras de negócio;

       3. Aperfeiçoamento       funções adicionais que aprimoram o software;

       4. Prevenção      evita a ocorrência de novos defeitos.

       As fases e passos na visão geral de engenharia de software são complementados por algumas
atividades guarda-chuva, tais como:

       •   Acompanhamento e controle do projeto;

       •   Revisões técnicas formais;

       •   Garantia de qualidade;

       •   Gestão de Configuração;

       •   Medição;

       •   Gestão de Risco.



1.4 O Processo de Software

        É uma estrutura comum de processo que define um pequeno número de atividades dessa
estrutura, que são aplicáveis a todos os projetos de software, independentemente do tamanho e
complexidade. Um conjunto de tarefas de engenharia, marcos de projeto, produtos do trabalho e
pontos de garantia da qualidade que permitem adaptar as atividades da estrutura às características do
projeto específico e às necessidades da equipe de projeto. Por fim, atividades guarda-chuva – garantia
da qualidade, gestão de configuração e medição – cobrem o modelo de processo. Essas atividades
guarda-chuva são independentes de qualquer atividade de estrutura e ocorrem ao longo de todo o
processo.

                  Estrutura comum de Processo
                          Atividades de estrutura

                             Conjuntos de tarefas
                                 Tarefas
                                 Marcos, produtos finais ou intermediários

                                 Pontos de garantia de qualidade


                      Atividades guarda-chuva


                                   Figura 02 – Estrutura comum de Processo

       Há algum tempo tem havido ênfase significativa na “maturidade do processo”. O Software
Engineering Institute – SEI desenvolveu um modelo abrangente, baseado num conjunto de
capacidades de engenharia de software que devem estar presentes à medida que as empresas alcançam
diferentes níveis de maturidade de processo, o Capability Maturity Model, atualmente reestruturado e
designado Capability Maturity Model Integration – CMMI.



1.5 Capability Maturity Modelo Integration

   - Um conjunto de disciplinas integradas:

       Software Engineering

       Systems Engineering

       Integrated Product and Process Development

       Suplier Sourcing

       People CMM



   - Formas de representação

       Contínua       Capacidade de cada área de processo

       Por Estágios      Maturidade da organização
- Áreas de Processo - PA’s

       Conjunto de práticas relacionadas, que quando executadas conjuntamente, satisfazem um
conjunto de metas consideradas importantes para promover melhoria naquela área. As PA’s são as
mesmas nas duas representações.

       Ex.: Planejamento de projeto, Gerenciamento de riscos, Gerenciamento de requisitos.

- Principais itens das PA’s

       1. Metas Específicas: CARACTERÍSTICA que precisa ser implementado para satisfazer a
          PA.

       2. Práticas Específicas: ATIVIDADE importante para implementar a característica anterior.

       3. Metas Genéricas: Descreve a INSTITUCIONALIZAÇÃO que a organização precisa
          alcançar para cada NÍVEL DE MATURIDADE.

       4. Práticas Genéricas: Promove a institucionalização, garantindo que o processo será
          EFETIVO, REPETÍVEL E DURADOURO.

- Modelo de Maturidade – Por Estágio
- Modelo de Capacidade - Contínuo
- Organização das Áreas de Processo




1.5 Paradigmas de Engenharia de Software

      Um modelo de processo ou paradigma é escolhido com base na natureza da aplicação, nos
métodos e ferramentas a serem usados, e nos controles e produtos intermediários e finais requeridos.

       O desenvolvimento de software pode ser caracterizado como um ciclo de solução de problema
(Figura 03), no qual a “Situação Atual” representa o estado atual das coisas, a “Definição do
Problema” identifica o problema a ser resolvido, o “Desenvolvimento Técnico” resolve o problema
por meio de alguma tecnologia e a “Integração da Solução” entrega os resultados (documentos,
programas, dados).

       Esse ciclo aplica-se ao trabalho de engenharia de software em muitos diferentes níveis de
resolução: em nível macro, quando a aplicação e considerada, em nível intermediário, quando os
componentes de programa esta sendo construídos e mesmo no nível de linha de código, como uma
representação FRACTAL (Figura 04).
Definição
                                           Problema
                         Situação                                                Desenvolv.
                          Atual                                                   Técnico
                                           Integração
                                            Solução

                        Figura 03 – Fases do Ciclo de Solução de Problema

                                                       Definição
                                                       Problema
                                            Situação                Desenvolv.
                                             Atual                   Técnico
                                                       Integração
                                                        Solução




                                                                                             Definição

                         Situação                                                 Situação
                                                                                   Atual
                                                                                             Problema



                                                                                             Integração
                                                                                                          Desenvolv.
                                                                                                           Técnico



                          Atual                                                               Solução




                                                       Definição
                                                       Problema
                                            Situação                Desenvolv.
                                             Atual                   Técnico
                                                       Integração
                                                        Solução




                                        Figura 04 – Fractal

1.6 Modelo Cascata
       Conhecido como abordagem ‘top-down’, tem como principal característica a sequência de
atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma
nova fase.

        Definição
        Requisitos
                         Projeto
                         Sistema
                                       Implementação

                                                                                  Teste
                                                                                 Sistema

                                                                                                                       Manutenção




                                         Documentação

                              Figura 05 - Descrição Visual do Modelo
A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem uma
sequência, ou seja, a saída da primeira etapa quot;fluíquot; para a segunda etapa e a saída da segunda etapa
quot;fluíquot; para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas
sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma
das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os
produtos finais da tarefa atual.
        O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que
quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez
que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas
anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas. Numa tentativa de
resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata,
designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade
de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar
alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior
conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um
processo de gestão do projeto e de controle das alterações bem definido, podemos passar o tempo num
ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema.
As desvantagens deste modelo são:
   •   Dificuldade em acomodar mudanças depois que o processo está sendo executado;
   •   Partição inflexível do projeto em estágios distintos;
   •   Dificuldade em responder a mudanças dos requisitos;
   •   É mais apropriado quando os requisitos são bem compreendidos;
   •   É difícil capturar os requisitos de uma só vez;
   •   Cliente tem de pacientemente esperar o resultado final;
   •   Os programadores são frequentemente atrasados sem necessidade;
   •   Alto custo de correção das especificações quando nas fases de Teste e Implantação.


1.7 Modelo de Prototipagem
        O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações
do modelo cascata. A idéia básica deste modelo é que ao invés de manter inalterado os requisitos
durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos
requisitos. Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destas
fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os
requisitos do sistema.
Análise de
             Requisitos


               Projeto                 Projeto            Codificação              Teste


            Codificação


               Teste


                            Figura 06 – Representação gráfica do modelo
        O protótipo é desenvolvido com uma versão inicial do documento de especificação dos
requisitos. Depois do protótipo estar pronto o cliente o utiliza e, baseado na sua avaliação, são
fornecidas as impressões do que precisa ser alterado, o que está faltando e o que não é preciso. O
protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo
novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os
requisitos iniciais são alterados para produzir a especificação final dos requisitos.
Segundo Pressman, este modelo pode trazer os seguintes benefícios:
   •   O modelo é interessante para alguns sistemas de grande porte nos quais representem um certo
       grau de dificuldade para exprimir rigorosamente os requisitos;
   •   É possível obter uma versão do que será o sistema com um pequeno investimento inicial;
   •   A experiência de produzir o protótipo pode reduzir o custo das fases posteriores;
   •   A construção do protótipo pode demonstrar a viabilidade do sistema.
Questões a serem consideradas quanto a utilização do modelo:
   •   A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no
       projeto;
   •   Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de
       prototipação;
   •   Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente
       será o mesmo do sistema final;
   •   Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos
       especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as
       técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na
       implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções
       etc)
•   Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no
       protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final.


1.7 Modelo Espiral
      Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando
uma versão de um software executável.
       O modelo em espiral foi proposto como forma de integrar os diversos modelos existentes à
época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido
para abranger as melhores características tanto do ciclo de vida clássico como da prototipação,
acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses
paradigmas.
        Entretanto, a integração não se dá através da simples incorporação de características dos
modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos,
cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase
(ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos.




                                      Figura 07 – Modelo Espiral


       O modelo espiral considera seis tarefas ou setores da espiral, como segue:
       •   Comunicação com o cliente: estabelecer efetiva comunicação entre desenvolvedor e
           cliente;
       •   Planejamento: definir recursos, prazos, orçamentos e outras informações de projeto;
       •   Análise de Risco: avaliar e tratar riscos técnicos e gerenciais;
       •   Engenharia: criar um ou mais modelo do software;
•   Construção e liberação: construir, testar, instalar e fornecer apoio ao usuário;
       •   Avaliação pelo cliente: obter realimentação do cliente com base nos modelos criados no
           estágio de engenharia e implementados durante a construção.
       O modelo espiral é atualmente a abordagem mais realística para desenvolvimento de software
em grande escala e usa uma abordagem que capacita a empresa que presta o serviço e o cliente a
entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável
experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil
convencer os clientes que uma abordagem evolutiva é controlável.

Vantagens deste modelo
   •   modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada
       vez mais completas, recorrendo à prototipagem para reduzir os riscos.
   •   Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata,
       mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o
       processo de desenvolvimento.

Desvantagens
   •   Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a
       abordagem evolutiva é controlável.
   •   A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e
       baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão
       ocorrer problemas.
   •

   •   É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O
       protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir
       somente alguns aspectos do sistema a ser desenvolvido.
   •   O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do
       projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de
       técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os
       indicadores de custo e progresso mais adequados.



1.8 Modelo iterativo e incremental
       Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.
       O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser
estendida por vários meses, possivelmente um ano ou mais. Por isso, é mais prático dividir o trabalho
em partes menores ou iterações. Cada iteração resultará num incremento.

       Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.
O princípio subjacente ao processo incremental e iterativo é que a equipe envolvida possa
 refinar e expandir paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.
         Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar a
 viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de desenho e
 implementação. Numa segunda geração, deve-se concluir a análise, fazer uma parte significativa do
 desenho e um pouco mais de implementação. Numa terceira iteração, deve-se concluir o desenho,
 fazer-se parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principal
 consequência da aproximação iterativa é que os produtos finais de todo o processo vão sendo
 amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de
 produtos finais.
         A cada iteração são realizadas as seguintes tarefas:
         •   Análise (refinamento de requisitos, refinamento do modelo conceitual);
         •   Projeto (refinamento do projeto arquitetural, projeto de baixo nível);
         •   Implementação (codificação e testes);
         •   Transição para produto (documentação, instalação, ...).



Planejamento
                   Análise
                                                                             1ª Versão
                                Desenho
                                                Desenvolv.
                                                                    Testes

                                            Análise
                                                                                              2ª Versão
                                                          Desenho
                                                                        Desenvolv.
                                                                                           Testes


                                                                                         Manutenção

                      Figura 08 – Representação do Modelo Iterativo e Incremental


         Vantagens do processo incremental e iterativo:
     •   Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas
         para os eliminar ou controlar;
•   Redução dos riscos envolvendo custos a um único incremento.Se a equipa que desenvolve o
       software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de
       uma iteração, não o valor de um produto inteiro;
   •   Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento;
   •   Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidos
       de alterações futuras;
   •   Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e
       partilha de comunicação daí resultante.


1.9 Conclusão
       Não existe um processo correto ou incorreto , como não existe um modelo de desenvolvimento
que seja a panacéia universal para o problema do desenvolvimento de software.
       Dependendo de sua aplicação, ambiente e objetivo, a utilização de um processo ou modelo
específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado e
usar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo de
desenvolvimento.

Mais conteúdo relacionado

Mais procurados

Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Softwareelliando dias
 
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFSlide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFEdton Lemos
 
Gerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptxGerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptxRoberto Nunes
 
Engenharia de Software
Engenharia de SoftwareEngenharia de Software
Engenharia de SoftwareSm3nd3s29
 
Aula9 TEES UFS Gestao de Configuração de SW
Aula9 TEES UFS  Gestao de Configuração de SWAula9 TEES UFS  Gestao de Configuração de SW
Aula9 TEES UFS Gestao de Configuração de SWRogerio P C do Nascimento
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de softwareDanilo Gois
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02Franklin Matos Correia
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Marcelo Schumacher
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Fernando Vargas
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixCris Fidelix
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixCris Fidelix
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em softwareVictor Hugo
 

Mais procurados (20)

152191 11993
152191 11993152191 11993
152191 11993
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAFSlide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAF
 
Gerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptxGerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptx
 
Revista Engenharia de Software n° 44
Revista Engenharia de Software n° 44Revista Engenharia de Software n° 44
Revista Engenharia de Software n° 44
 
Engenharia de Software
Engenharia de SoftwareEngenharia de Software
Engenharia de Software
 
O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012
 
Aula9 TEES UFS Gestao de Configuração de SW
Aula9 TEES UFS  Gestao de Configuração de SWAula9 TEES UFS  Gestao de Configuração de SW
Aula9 TEES UFS Gestao de Configuração de SW
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
ISO IEC 12207
ISO IEC 12207ISO IEC 12207
ISO IEC 12207
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em software
 

Destaque

Onde está a minha paixão
Onde está a minha paixão Onde está a minha paixão
Onde está a minha paixão Paulo Da Rocha
 
Tecnologias Inovadoras e Eficientes na Gestão de Pessoas
Tecnologias Inovadoras e Eficientes na Gestão de PessoasTecnologias Inovadoras e Eficientes na Gestão de Pessoas
Tecnologias Inovadoras e Eficientes na Gestão de PessoasLuiz Mauricio
 
Cinco P’s para Estratégia
Cinco P’s para EstratégiaCinco P’s para Estratégia
Cinco P’s para EstratégiaAndre Silva
 
Movimento de crescimento de igreja
Movimento de crescimento de igrejaMovimento de crescimento de igreja
Movimento de crescimento de igrejaHaroldo Xavier Silva
 
Princípios de Liderança Eclesiástica
Princípios de Liderança EclesiásticaPrincípios de Liderança Eclesiástica
Princípios de Liderança EclesiásticaJoão Carlos
 
Qual é a nossa função no corpo da igreja?
Qual é a nossa função no corpo da igreja?Qual é a nossa função no corpo da igreja?
Qual é a nossa função no corpo da igreja?Leandro Sales
 

Destaque (10)

Onde está a minha paixão
Onde está a minha paixão Onde está a minha paixão
Onde está a minha paixão
 
Gestao Projetos - Aula 01
Gestao Projetos - Aula 01Gestao Projetos - Aula 01
Gestao Projetos - Aula 01
 
Tecnologias Inovadoras e Eficientes na Gestão de Pessoas
Tecnologias Inovadoras e Eficientes na Gestão de PessoasTecnologias Inovadoras e Eficientes na Gestão de Pessoas
Tecnologias Inovadoras e Eficientes na Gestão de Pessoas
 
Cinco P’s para Estratégia
Cinco P’s para EstratégiaCinco P’s para Estratégia
Cinco P’s para Estratégia
 
Mapeamento processos
Mapeamento processosMapeamento processos
Mapeamento processos
 
Bpm
BpmBpm
Bpm
 
Evangelho no lar
Evangelho no larEvangelho no lar
Evangelho no lar
 
Movimento de crescimento de igreja
Movimento de crescimento de igrejaMovimento de crescimento de igreja
Movimento de crescimento de igreja
 
Princípios de Liderança Eclesiástica
Princípios de Liderança EclesiásticaPrincípios de Liderança Eclesiástica
Princípios de Liderança Eclesiástica
 
Qual é a nossa função no corpo da igreja?
Qual é a nossa função no corpo da igreja?Qual é a nossa função no corpo da igreja?
Qual é a nossa função no corpo da igreja?
 

Semelhante a Aula 02

Fabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasFabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasAnnkatlover
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareElaine Cecília Gatto
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Elaine Cecília Gatto
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - WikipediaRobson Silva Espig
 
Mineração de Dados Aplicada em Engenharia de Software
Mineração de Dados Aplicada em Engenharia de SoftwareMineração de Dados Aplicada em Engenharia de Software
Mineração de Dados Aplicada em Engenharia de SoftwareBruno Alisson
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdfa29398
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9wilsonguns
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfpedrina4
 
Engenharia de Software: A ponte para um código sustentável
Engenharia de Software: A ponte para um código sustentávelEngenharia de Software: A ponte para um código sustentável
Engenharia de Software: A ponte para um código sustentávelFernando Pontes
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWAula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWRogerio P C do Nascimento
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareCursoSENAC
 

Semelhante a Aula 02 (20)

Fabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasFabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.Aprendidas
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de Software
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - Wikipedia
 
Mineração de Dados Aplicada em Engenharia de Software
Mineração de Dados Aplicada em Engenharia de SoftwareMineração de Dados Aplicada em Engenharia de Software
Mineração de Dados Aplicada em Engenharia de Software
 
ISO IEC 12207
ISO IEC 12207ISO IEC 12207
ISO IEC 12207
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Processo de Software
Processo de SoftwareProcesso de Software
Processo de Software
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Engenharia de Software: A ponte para um código sustentável
Engenharia de Software: A ponte para um código sustentávelEngenharia de Software: A ponte para um código sustentável
Engenharia de Software: A ponte para um código sustentável
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
 
DevOps
DevOpsDevOps
DevOps
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWAula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 

Mais de Robson Silva Espig (20)

Master Place - Convenção Bloco D
Master Place - Convenção Bloco DMaster Place - Convenção Bloco D
Master Place - Convenção Bloco D
 
Aquarelas Envelhecidas
Aquarelas EnvelhecidasAquarelas Envelhecidas
Aquarelas Envelhecidas
 
[ reference ] Processos - PMBOK
[ reference ] Processos - PMBOK[ reference ] Processos - PMBOK
[ reference ] Processos - PMBOK
 
[ ref ] Convergência - Mobilidade
[ ref ] Convergência - Mobilidade[ ref ] Convergência - Mobilidade
[ ref ] Convergência - Mobilidade
 
[ ref ] Normalizing a Data Model in SQL Server
[ ref ] Normalizing a Data Model in SQL Server[ ref ] Normalizing a Data Model in SQL Server
[ ref ] Normalizing a Data Model in SQL Server
 
A Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareA Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de Software
 
Como implementar uma plataforma de ILM com eficiência, reduzindo custos
Como implementar uma plataforma de ILM com eficiência, reduzindo custosComo implementar uma plataforma de ILM com eficiência, reduzindo custos
Como implementar uma plataforma de ILM com eficiência, reduzindo custos
 
Gestao Projetos - Aula 02
Gestao Projetos - Aula 02Gestao Projetos - Aula 02
Gestao Projetos - Aula 02
 
Aula 01
Aula 01Aula 01
Aula 01
 
Aula 05
Aula 05Aula 05
Aula 05
 
Aula 04
Aula 04Aula 04
Aula 04
 
Caso de Desenvolvimento
Caso de DesenvolvimentoCaso de Desenvolvimento
Caso de Desenvolvimento
 
SOA
SOASOA
SOA
 
Aula 03
Aula 03Aula 03
Aula 03
 
Artigo Caso de Uso
Artigo Caso de UsoArtigo Caso de Uso
Artigo Caso de Uso
 
RAD
RADRAD
RAD
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Desenvolvimento Iterativo e Incremental
Desenvolvimento Iterativo e IncrementalDesenvolvimento Iterativo e Incremental
Desenvolvimento Iterativo e Incremental
 
Implantacao de Software
Implantacao de SoftwareImplantacao de Software
Implantacao de Software
 
Manutencao de Software
Manutencao de SoftwareManutencao de Software
Manutencao de Software
 

Último

Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORDRONDINELLYRAMOS1
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 

Último (7)

Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORD
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 

Aula 02

  • 1. ENGENHARIA DE SOFTWARE Aula 02 Prof. Cleuber Moreira Fernandes Mestre em Ciência da Computação - UnB Cleubermf@yahoo.com.br http://br.groups.yahoo.com/group/ES-2008
  • 2. 1. Engenharia de Software 1.1 Definição Segundo Frits Bauer: “É a criação e utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais.” • Não considera diretamente aspectos como: a) Qualidade – satisfação do cliente e pontualidade; b) Importância de métricas e de processo amadurecido. • Linha básica: a) Quais são os sólidos princípios? b) Equilíbrio economicidade e confiabilidade; c) Softwares eficientes em diferentes máquinas reais. 1.2 Processos, métodos e ferramentas Engenharia está sempre apoiada na gestão de qualidade total que leva a uma cultura de processo contínuo de melhoria. O fundamento da engenharia de software é a camada de PROCESSO, que define uma estrutura para um conjunto de áreas de processo – PA (Gestão Configuração, Gestão Requisitos, ...). Os processos estabelecem quando, onde e como os métodos são aplicados para produzir os produtos de trabalho (documentos, dados, relatórios), definem os marcos do projeto e gerenciam a qualidade. Os métodos fornecem as técnicas para construir software, com tarefas que abrangem análise de requisitos, projeto, implementação, teste e implantação. Ferramentas consistem no apoio automatizado ou semi-automatizado para o processo e para os métodos. A engenharia de software apoiada por computador – CASE combina software, hardware e base de dados (informações sobre análise, projeto, teste, ...) para criar um ambiente de engenharia. Ferramentas Métodos Processos Foco na qualidade Figura 01 – Camadas da Engenharia de Software
  • 3. 1.3 Abstração de Engenharia de Software Engenharia é a análise, projeto, construção verificação e gestão de elementos técnicos ou sociais. Independente do produto ou solução, as seguintes perguntas precisam ser respondidas: a) Qual é o problema a ser resolvido? b) Que características do produto/solução são usadas para resolver o problema? c) Como os produtos serão construídos? d) Que abordagem será usada para descobrir erros cometidos no projeto e construção do produto? e) Como o produto será mantido a longo prazo, quando da necessidade de correções, adaptações e aperfeiçoamentos? O trabalho associado à engenharia de software pode ser realizado em três fases genéricas, cada qual responde a uma ou mais das perguntas acima. Abaixo é apresentada uma combinação das classificações dadas por Schwartz, Pressman e Sommerville: 1. Especificação ou Definição O quê Visa identificar: informação, função, desempenho, restrições de projeto e critérios de aceitação. • Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extra-software; • Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento; • Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação. 2. Desenvolvimento Como Como os dados devem ser estruturados, como a função deve ser implementada dentro da arquitetura de software projetada para se alcançar o desempenho desejado, como as interfaces devem ser caracterizadas, como o projeto deve ser traduzido numa linguagem de programação e como o teste vai ser realizado. 2.1 Projeto • Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes; • Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida • Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.
  • 4. 2.2 Implementação • Codificação: a implementação em si do sistema em uma linguagem de computador. 2.3 Validação • Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema; • Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto. 3. Manutenção Foco nas modificações associadas com a correção de erros e adaptações à medida que o ambiente do software evolui e os requisitos dos clientes se modificam. Esta fase aplica novamente os conceitos das fases de Definição e Desenvolvimento, mas no contexto de software existente. Quatro tipos de modificações são realizadas: 1. Correção manuteção corretiva – eliminação defeitos; 2. Adaptação mudanças no ambiente computacional, regras de negócio; 3. Aperfeiçoamento funções adicionais que aprimoram o software; 4. Prevenção evita a ocorrência de novos defeitos. As fases e passos na visão geral de engenharia de software são complementados por algumas atividades guarda-chuva, tais como: • Acompanhamento e controle do projeto; • Revisões técnicas formais; • Garantia de qualidade; • Gestão de Configuração; • Medição; • Gestão de Risco. 1.4 O Processo de Software É uma estrutura comum de processo que define um pequeno número de atividades dessa estrutura, que são aplicáveis a todos os projetos de software, independentemente do tamanho e complexidade. Um conjunto de tarefas de engenharia, marcos de projeto, produtos do trabalho e pontos de garantia da qualidade que permitem adaptar as atividades da estrutura às características do projeto específico e às necessidades da equipe de projeto. Por fim, atividades guarda-chuva – garantia da qualidade, gestão de configuração e medição – cobrem o modelo de processo. Essas atividades
  • 5. guarda-chuva são independentes de qualquer atividade de estrutura e ocorrem ao longo de todo o processo. Estrutura comum de Processo Atividades de estrutura Conjuntos de tarefas Tarefas Marcos, produtos finais ou intermediários Pontos de garantia de qualidade Atividades guarda-chuva Figura 02 – Estrutura comum de Processo Há algum tempo tem havido ênfase significativa na “maturidade do processo”. O Software Engineering Institute – SEI desenvolveu um modelo abrangente, baseado num conjunto de capacidades de engenharia de software que devem estar presentes à medida que as empresas alcançam diferentes níveis de maturidade de processo, o Capability Maturity Model, atualmente reestruturado e designado Capability Maturity Model Integration – CMMI. 1.5 Capability Maturity Modelo Integration - Um conjunto de disciplinas integradas: Software Engineering Systems Engineering Integrated Product and Process Development Suplier Sourcing People CMM - Formas de representação Contínua Capacidade de cada área de processo Por Estágios Maturidade da organização
  • 6. - Áreas de Processo - PA’s Conjunto de práticas relacionadas, que quando executadas conjuntamente, satisfazem um conjunto de metas consideradas importantes para promover melhoria naquela área. As PA’s são as mesmas nas duas representações. Ex.: Planejamento de projeto, Gerenciamento de riscos, Gerenciamento de requisitos. - Principais itens das PA’s 1. Metas Específicas: CARACTERÍSTICA que precisa ser implementado para satisfazer a PA. 2. Práticas Específicas: ATIVIDADE importante para implementar a característica anterior. 3. Metas Genéricas: Descreve a INSTITUCIONALIZAÇÃO que a organização precisa alcançar para cada NÍVEL DE MATURIDADE. 4. Práticas Genéricas: Promove a institucionalização, garantindo que o processo será EFETIVO, REPETÍVEL E DURADOURO. - Modelo de Maturidade – Por Estágio
  • 7. - Modelo de Capacidade - Contínuo
  • 8. - Organização das Áreas de Processo 1.5 Paradigmas de Engenharia de Software Um modelo de processo ou paradigma é escolhido com base na natureza da aplicação, nos métodos e ferramentas a serem usados, e nos controles e produtos intermediários e finais requeridos. O desenvolvimento de software pode ser caracterizado como um ciclo de solução de problema (Figura 03), no qual a “Situação Atual” representa o estado atual das coisas, a “Definição do Problema” identifica o problema a ser resolvido, o “Desenvolvimento Técnico” resolve o problema por meio de alguma tecnologia e a “Integração da Solução” entrega os resultados (documentos, programas, dados). Esse ciclo aplica-se ao trabalho de engenharia de software em muitos diferentes níveis de resolução: em nível macro, quando a aplicação e considerada, em nível intermediário, quando os componentes de programa esta sendo construídos e mesmo no nível de linha de código, como uma representação FRACTAL (Figura 04).
  • 9. Definição Problema Situação Desenvolv. Atual Técnico Integração Solução Figura 03 – Fases do Ciclo de Solução de Problema Definição Problema Situação Desenvolv. Atual Técnico Integração Solução Definição Situação Situação Atual Problema Integração Desenvolv. Técnico Atual Solução Definição Problema Situação Desenvolv. Atual Técnico Integração Solução Figura 04 – Fractal 1.6 Modelo Cascata Conhecido como abordagem ‘top-down’, tem como principal característica a sequência de atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase. Definição Requisitos Projeto Sistema Implementação Teste Sistema Manutenção Documentação Figura 05 - Descrição Visual do Modelo
  • 10. A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem uma sequência, ou seja, a saída da primeira etapa quot;fluíquot; para a segunda etapa e a saída da segunda etapa quot;fluíquot; para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controle das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema. As desvantagens deste modelo são: • Dificuldade em acomodar mudanças depois que o processo está sendo executado; • Partição inflexível do projeto em estágios distintos; • Dificuldade em responder a mudanças dos requisitos; • É mais apropriado quando os requisitos são bem compreendidos; • É difícil capturar os requisitos de uma só vez; • Cliente tem de pacientemente esperar o resultado final; • Os programadores são frequentemente atrasados sem necessidade; • Alto custo de correção das especificações quando nas fases de Teste e Implantação. 1.7 Modelo de Prototipagem O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações do modelo cascata. A idéia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos. Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os requisitos do sistema.
  • 11. Análise de Requisitos Projeto Projeto Codificação Teste Codificação Teste Figura 06 – Representação gráfica do modelo O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos. Depois do protótipo estar pronto o cliente o utiliza e, baseado na sua avaliação, são fornecidas as impressões do que precisa ser alterado, o que está faltando e o que não é preciso. O protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos. Segundo Pressman, este modelo pode trazer os seguintes benefícios: • O modelo é interessante para alguns sistemas de grande porte nos quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos; • É possível obter uma versão do que será o sistema com um pequeno investimento inicial; • A experiência de produzir o protótipo pode reduzir o custo das fases posteriores; • A construção do protótipo pode demonstrar a viabilidade do sistema. Questões a serem consideradas quanto a utilização do modelo: • A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no projeto; • Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de prototipação; • Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente será o mesmo do sistema final; • Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções etc)
  • 12. Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final. 1.7 Modelo Espiral Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando uma versão de um software executável. O modelo em espiral foi proposto como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses paradigmas. Entretanto, a integração não se dá através da simples incorporação de características dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos. Figura 07 – Modelo Espiral O modelo espiral considera seis tarefas ou setores da espiral, como segue: • Comunicação com o cliente: estabelecer efetiva comunicação entre desenvolvedor e cliente; • Planejamento: definir recursos, prazos, orçamentos e outras informações de projeto; • Análise de Risco: avaliar e tratar riscos técnicos e gerenciais; • Engenharia: criar um ou mais modelo do software;
  • 13. Construção e liberação: construir, testar, instalar e fornecer apoio ao usuário; • Avaliação pelo cliente: obter realimentação do cliente com base nos modelos criados no estágio de engenharia e implementados durante a construção. O modelo espiral é atualmente a abordagem mais realística para desenvolvimento de software em grande escala e usa uma abordagem que capacita a empresa que presta o serviço e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável. Vantagens deste modelo • modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos. • Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento. Desvantagens • Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável. • A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas. • • É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido. • O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados. 1.8 Modelo iterativo e incremental Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso. O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais. Por isso, é mais prático dividir o trabalho em partes menores ou iterações. Cada iteração resultará num incremento. Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.
  • 14. O princípio subjacente ao processo incremental e iterativo é que a equipe envolvida possa refinar e expandir paulatinamente a qualidade, detalhe e âmbito do sistema envolvido. Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar a viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de desenho e implementação. Numa segunda geração, deve-se concluir a análise, fazer uma parte significativa do desenho e um pouco mais de implementação. Numa terceira iteração, deve-se concluir o desenho, fazer-se parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principal consequência da aproximação iterativa é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de produtos finais. A cada iteração são realizadas as seguintes tarefas: • Análise (refinamento de requisitos, refinamento do modelo conceitual); • Projeto (refinamento do projeto arquitetural, projeto de baixo nível); • Implementação (codificação e testes); • Transição para produto (documentação, instalação, ...). Planejamento Análise 1ª Versão Desenho Desenvolv. Testes Análise 2ª Versão Desenho Desenvolv. Testes Manutenção Figura 08 – Representação do Modelo Iterativo e Incremental Vantagens do processo incremental e iterativo: • Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar;
  • 15. Redução dos riscos envolvendo custos a um único incremento.Se a equipa que desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro; • Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento; • Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidos de alterações futuras; • Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha de comunicação daí resultante. 1.9 Conclusão Não existe um processo correto ou incorreto , como não existe um modelo de desenvolvimento que seja a panacéia universal para o problema do desenvolvimento de software. Dependendo de sua aplicação, ambiente e objetivo, a utilização de um processo ou modelo específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado e usar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo de desenvolvimento.