Universidade Federal do Espírito Santo Centro ... · Processo de Software 3. ... - Processos de Reúso de Software ISO /IEC 12207 :2008 - Processos Contratos Aquisição Fornecimento

1

Universidade Federal do Espírito Santo

Centro Tecnológico

Departamento de Informática

Prof.: Monalessa Perini Barcellos

([email protected])

Disciplina: INF 09289 – Engenharia de Software

Conteúdo

1. Introdução

2. Processo de Software

3. Especificação e Análise de Requisitos

4. Projeto de Sistema

5. Implementação e Testes

6. Entrega e Manutenção

7. Gerência da Qualidade

8. Gerência de Projetos de Software

9. Tópicos Avançados em Engenharia de SoftwareEngenharia de Software Monalessa Perini Barcellos

2

9. Tópicos Avançados em Engenharia de Software

Engenharia de Software Monalessa Perini Barcellos

• Estudos mostram que a qualidade do produto de software

depende diretamente da qualidade dos processos adotados no

seu desenvolvimento (FUGGETTA, 2000).

• Cada vez mais, as organizações têm despendido esforços

significativos na melhoria contínua de seus processos de

software.

• Algumas iniciativas:

Normas e modelos de qualidade de processo

Processos de software padrão

Desenvolvimento por meio de processos ágeis

Apoio automatizado ao processo de software.



• Estudos mostram que a qualidade do produto de software

depende diretamente da qualidade dos processos adotados no

seu desenvolvimento (FUGGETTA, 2000).

• Cada vez mais, as organizações têm despendido esforços

significativos na melhoria contínua de seus processos de

software.

• Algumas iniciativas:

Normas e modelos de qualidade de processo

Processos de software padrão

Desenvolvimento por meio de processos ágeis

Apoio automatizado ao processo de software.

3



Auxiliam a “rechear” o arcabouço fornecido pelo modelo de ciclo de vida.

Fases Atividades Responsáveis Produtos

Análise

Realizar levantamento de requisitos.

Elaborar especificação de requisitos.

Avaliar especificação de requisitos.

Analista.

Usuários.

Especificação de requisitos do

sistema.

Projeto

Elaborar projeto de dados.

Elaborar projeto de arquitetura.

Elaborar projeto de interface.

Avaliar projeto.

Projetista de

sistemas.Projeto do sistema.

Codificação

Implementar a base de dados.

Implementar cada unidade de

software do sistema.

Programador. Sistema codificado.

Testes

Preparar planejamento de testes.

Realizar testes de codificação.

Realizar testes funcionais.

Analista.

Programador.

Usuário.

Planejamento de casos de

testes.

Relatório de testes realizados.

ManutençãoRealizar correção/evolução.

Realizar testes de manutenção.

Analista.

Programador.

Usuário.

Relatório de manutenções

realizadas.

Algumas normas e

modelos podem

ajudar a definição de

processos.

A) Normas e Modelos de Apoio à Definição de Processos


Normas e Modelos de Apoio à Definição de Processos

A Série ISO 9000:2000

Desenvolvida para apoiar organizações, de todos os tipos e tamanhos, na

implementação e operação de sistemas eficazes de gestão da qualidade.

• NBR ISO 9000: descreve os fundamentos de sistemas de gestão da qualidade e

estabelece a terminologia para esses sistemas;

• NBR ISO 9001: especifica os requisitos para um sistema de gestão da qualidade

com enfoque na satisfação do cliente. Para uma organização ser certificada ISO

9001, ela precisa demonstrar sua capacidade para fornecer produtos que atendam

aos requisitos do cliente (explícitos e implícitos) e os requisitos regulamentares

aplicáveis;

• NBR ISO 9004: fornece diretrizes que consideram tanto a eficácia como a

eficiência do sistema de gestão da qualidade. Amplia os requisitos estabelecidos

pela ISO 9001, buscando melhoria contínua de desempenho.

• NBR ISO 19011: fornece diretrizes sobre auditoria internas e externas de sistemas

de gestão da qualidade.


4

1. A empresa estabelece o seu sistema da qualidade.

2. A empresa faz uma solicitação formal a um órgão certificador.

3. O órgão certificador faz uma primeira visita à empresa para colher mais

dados e explicar o processo de certificação.

4. O órgão certificador verifica se a documentação do sistema da qualidade está

de acordo com a ISO.

5. O órgão certificador envia uma equipe à empresa com fins de auditoria.

Podem ocorrer três situações:

Qualificada sem discrepâncias

Qualificada com pequenas discrepâncias, que devem ser corrigidas em um

prazo pré-estabelecido antes da certificação

Não qualificada

6. O órgão certificador realiza visitas periódicas à empresa para assegurar que

o sistema continua sendo efetivo.

ISO 9001 - Processo de Certificação



ISO 9001:2000 - Certificado



Certificado ISO 9001:2000 entregue ao

Club Atletico Boca Juniors

(Argentina)

Escopo da certificação: Eventos Esportivos

5

ISO 12207 - Tecnologia de Informação - Processos de Ciclo de Vida de Software



• 43 processos + um processo de adaptação.

• 7 categorias:

- Processos relacionados a Acordos (Contratos)

- Processos relacionados à Habilitação Organizacional para Projetos

- Processos de Projeto

- Processos Técnicos

- Processos de Implementação do Software

- Processos de Apoio ao Software

- Processos de Reúso de Software

ISO /IEC 12207 :2008 - Processos

Contratos

Aquisição

Fornecimento

Habilitação Organizacionalpara Projetos

Gerência do MCV

Gerência de Infraestrutura

Gerência de Portfólio

Gerência de RH

Gerência da Qualidade

Projetos

Planejamento de Projetos

Acompanhamento e Controle de

Projetos

Gerência de Decisão

Gerência de Riscos

Gerência da Configuração

Gerência da Informação

Medição

Técnicos

Definição dos Requisitos dos Stakeholders

Análise de Requisitos do

Sistema

Arquitetura do Sistema

Implementação

Teste de Qualificação do

Sistema

Instalação do Software

Apoio à Aceitação do Software

Integração

Operação do Software

Manutenção do Software

Descontinuação do Software

Implementação do Software

Implementação do Software

Análise de Requisitos do

Software

Projeto da Arquitetura do

Software

Projeto Detalhado do Software

Construção do Software

Integração do Software

Teste de Qualificação do

Software

Apoio

Gerência de Documentação do

Software

Gerência de Configuração do

Software

Garantia da Qualidade do Software

Verificação do Software

Validação do Software

Revisão do Software

Auditoria do Software

Resolução de Problemas do Software

Reúso de Software

Engenharia deDomínio

Gerência dos Ativos de Reúso

Gerência do Programa de Reúso

Processos Específicos de SoftwareProcessos para o Contexto de Sistemas

6

• Definido pelo Software Engineering Institute (SEI) - Carnegie Mellon University, com o

intuito de quantificar a capacidade de uma organização produzir produtos de

software de alta qualidade, de forma previsível e consistente.

• Descreve princípios e práticas dos quais depende a maturidade do processo de

software.

• Define 5 níveis de maturidade para o processo de desenvolvimento que são

caracterizados por PA’s (Process Areas).

• Tem como objetivo auxiliar as organizações a aumentarem a maturidade de seus

processos por um caminho evolutivo.

• Pode ser usado por empresas contratantes para identificar as características do

processo utilizado por seus fornecedores.

• Oferece duas abordagens para melhoria de processos: contínua ou por estágios.

CMMI - Capability Maturity Model Integration



CMMI - Capability Maturity Model Integration



1Processo imprevisível, fracamente controlado e reativo

2Processo caracterizado para projetos e muitas vezes reativo

3Processo caracterizado para a organização e pró-ativo

4Desempenho do processo controlado estatisticamente

5Foco na melhoria contínua do processo

Inicial

Gerenciado

Definido

Gerenciado Quantitativamente

Em Otimização

7

• Originalmente: SPICE (Software Process Improvement and Capability dEtermination) - é

um padrão internacional ISO para avaliação de processos de software.

• É composta de cinco partes:

i. Part 1 – Concepts and Vocabulary (Conceitos e Vocabulário);

ii. Part 2 – Performing an Assessment (Realizando uma Avaliação);

iii. Part 3 – Guidance on Performing an Assessment (Orientações para se Realizar uma

Avaliação);

iv. Part 4 – Guidance on use for Process Improvement and Process Capability Determination

(Orientações para Uso em Melhoria de Processo e Determinação da Capacidade de

Processo);

v. Part 5 – An exemplar Process Assessment Model (Um Exemplo de Modelo de Avaliação de

Processo).

A Norma ISO/IEC 15504 - Information Technology – Process Assessment



• Baseou-se na ISO 15504 e no CMMI.

• Possui 3 componentes: Modelo de Referência (MR-MPS), Método de

Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).

• Define sete níveis de maturidade: A (Em Otimização), B (Gerenciado

Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente

Definido), F (Gerenciado) e G (Parcialmente Gerenciado).

MR MPS.BR - Modelo de Referência para Melhoria de Processo de Software Brasileiro



8

MR MPS-SW - Modelo de Referência para Melhoria de Processo de Software Brasileiro



Nível ProcessosA Análise de Causas de Problemas e Resolução

B Gerência de Projetos (evolução)

C Análise de Decisão e Resolução

Desenvolvimento para Reutilização

Gerência de Riscos

Gerência de Reutilização (evolução)

D Desenvolvimento de Requisitos

Projeto e Construção do Produto

Integração do Produto

Verificação

Validação

E Avaliação e Melhoria de Processo Organizacional

Definição do Processo Organizacional

Gerência de Recursos Humanos

Gerência de Reutilização

Gerência de Projetos (evolução)

F Medição (para monitoração e controle)

Gerência de Configuração

Aquisição

Garantia da Qualidade

Gerência de Portfólio

G Gerência de Requisitos

Gerência de Projetos



• Embora diferentes projetos requeiram processos com características específicas

para atender às suas particularidades, é possível estabelecer um conjunto de

ativos de processo* a ser utilizado na definição de processos de software de

uma organização.

• As normas e modelos preconizam a definição e institucionalização de processos

padrão nas organizações.

* Subprocessos, atividades, subatividades, artefatos, recursos e procedimentos, dentre outros.

Processo PadrãoNormas e Modelos de Qualidade

Cultura Organizacional, Política Organizacional,

Características da Organização etc

B) Definição de Processos de Software em Níveis

9



Processo Padrão

Normas e Modelos de Qualidade, Cultura Organizacional,

Características da Organização

Tipo de Software, Domínio do Problema, Paradigma e

Tecnologia de Desenvolvimento

Particularidades do Projeto, Modelo de Ciclo de Vida

Definição

Especialização

Processo Especializado 1 Processo Especializado n

Instanciação

Processo de Projeto mProcesso de Projeto 1



C) Processos Ágeis

O Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à

esquerda.”

(http://manifestoagil.com.br/)

10



XP – eXtreme Programming

• Abordagem para desenvolvimento de software que busca assegurar que o cliente

receba o máximo de valor a cada dia de trabalho da equipe de desenvolvimento.

• Parte da premissa de que o cliente aprende sobre suas necessidades na medida em que é capaz de manipular o sistema sendo produzido. Com base no uso do sistema,

o cliente reavalia suas necessidades e prioridades, gerando mudanças que devem ser incorporadas ao software pela equipe de desenvolvimento.

• XP é voltado para:

Projetos cujos requisitos são vagos e podem mudar com frequência Desenvolvimento de sistemas orientados a objetos

Equipes pequenas (até 12 desenvolvedores) Desenvolvimento iterativo/incremental (o sistema começa a ser

implementado logo no início e vai ganhando novas funcionalidades ao longo do tempo).



• XP é organizado em torno de um conjunto de valores e práticas que devem atuar

de maneira coesa e harmônica.

• Valores do XP:

Feedback: quando o cliente aprende com o sistema que utiliza, ele reavalia

as suas necessidades e dá feedback para a equipe de desenvolvimento.

Comunicação: a comunicação entre o cliente e a equipe permite que todos

os detalhes do projeto sejam tratados com a atenção e agilidade que

merecem.

Simplicidade: a simplicidade advoga que só deve ser implementado aquilo

que é suficiente para atender as necessidades do cliente.

Coragem: a equipe precisa ter coragem e acreditar que, usando as práticas e

valores do XP, será capaz de fazer o software evoluir com segurança e

agilidade.

11



• O XP não possui uma figura padrão que represente a metodologia como um

processo (sequência de passos).

• A figura clássica do XP é conhecida como 3 loops e apresenta suas 13 práticas.



• Método ágil para gerenciamento de projetos, cuja aplicação não está limitada a

projetos de software.

• O nome foi inspirado em um trabalho publicado na Harward Business Review em

1986, intitulado “The New New Product Development Game” , de Hirotaka

Takeuchi e Ikujiro Nonaka, que propunha uma abordagem e a comparava com a

formação Scrum no rugby.

• Foi formalmente criado no artigo “Scrum and the Perfect Storm”

(www.controlcaos.com/my-articles) escrito por Ken Schwaber na década de 90, baseado

no desenvolvimento iterativo e incremental e novas estratégias de criação de

produtos.

• O nome foi inspirado em uma jogada de Rugby. Após uma reunião (agrupamento

em torno da bola), o objetivo é retirar os obstáculos à frente do jogador que correrá

com a bola, para que possa avançar o máximo possível no campo e marcar pontos.

SCRUM

12

Ciclo do SCRUM



Como funciona:

1. Os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. A Sprint representa uma

janela de tempo dentro da qual um conjunto de atividades deve ser executado. Normalmente uma sprint

dura de 2 a 4 semanas.

2. As funcionalidades a serem implementadas em um projeto são mantidas em uma lista chamada Product

Backlog.

3. No início de cada Sprint, faz-se uma reunião de planejamento inicial (Sprint Planning Meeting) na qual

Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de

implementar durante a Sprint que se inicia.

4. As atividades alocadas em uma Sprint são transferidas do Product Backlog para o Sprint Backlog.

5. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum

(também é conhecida como Stand up Meeting) para disseminar conhecimento sobre o que foi feito no dia

anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

6. Ao final de uma Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review

Meeting.

7. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento da próxima Sprint.


13



• Com o aumento da complexidade dos processos de software, tornou-se

imprescindível utilizar ferramentas e ambientes de apoio à realização de suas

atividades, visando, sobretudo, a atingir níveis mais altos de qualidade e

produtividade.

• Ferramentas CASE (Computer Aided Software Engineering) apoiam a realização de

atividades específicas, tais como planejamento e análise e especificação de

requisitos.

• Atualmente, o elevado número e a variedade de ferramentas CASE levou os

engenheiros de software a pensarem em trabalhar com diversas ferramentas que

interajam entre si e forneçam suporte a todo ciclo de vida do desenvolvimento,

dando origem aos Ambientes de Desenvolvimento de Software (ADSs).

D) Automatização de Processo de Software

Universidade Federal do Espírito Santo

Centro Tecnológico

Departamento de Informática

Prof.: Monalessa Perini Barcellos

([email protected])

Disciplina: INF 09289 – Engenharia de Software

Documents

Universidade Federal do Espírito Santo Centro ... · Processo de Software 3. ... - Processos de Reúso de Software ISO /IEC 12207 :2008 - Processos Contratos Aquisição Fornecimento