Engenharia de Software II

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Conjunto de atividade coerentes e consistentes para especificar,

projetar, implementar e testar um software.

È uma representação abstrata de como esta realizada a construção do

software.

PARA QUE PROCESSOS ?

Para definir as atividades a serem conduzidas no projeto.

Para uniformizar o entendimento dos envolvidos me relação ao

desenvolvimento de sistemas.

Para manter a consistência ente os sistemas desenvolvidos em uma

mesma empresa.

Para viabilizar os pontos de controle para gerencia.

PROCESSO PESSOAL DE SOFTWARE (PSP)

Sugere praticas e métodos para que o próprio individuo possa

identificar e corrigir os seus pontos fracos.

É uma sugestão para organização e disciplina o indivíduo, e não para

limitar a sua capacidade de criação.

Possui 7 etapas sequenciais e progressivas, cada uma com um conjunto

de roteiros e formulários disponíveis em : www.sei.cmu.edu.

OBJETIVOS SO PSP :

- Melhorar o planejamento;

- Melhoria das estimativas de prazos;

- Estabelecer processos de revisão de projeto e código;

- Gerenciar a qualidade;

- Executar a fase de projeto de maneira mais formal;

- Identificar pontos de melhora de qualidade.

O TSP É BASEADO NO PSP E ESTABELECER UM FRAMEWORK PARA :

- Planejar e gerenciar um projeto em equipe;

- Definir processos – Incremental;

- Distribuir papeis – Disciplina;

- Construir um trabalho em equipe ;

- Estabelecer medidas de qualidade;

- Ter equipes eficazes.

EQUIPES EFICAZES POSSUEM :

- Objetivos definidos, realistas e tangível;

- Recursos são suficientes para trabalho;

- Membros qualificados;

- Time motivado e empenhado em cumprir os objetivos;

- Membros cooperam e apoiam uns aos outros;

- Membros são disciplinados em seu trabalho.

- Estabelecer objetivos e papeis;

- Definir um processo comum de trabalho;

- Envolver todos na produção do plano e negociar o plano de gerencia;

- Treinar previamente em PSP.

INTERATIVIDADE 1

RESPOSTA CERTA É : d) fase de elaboração.

MODELOS E CICLO DE VIDA DE SOFTWARE

Definem um conjunto destinto de atividades , ações, tarefas, marcos e

produtos de trabalho que são necessários para fazer a engenharia de
software com alta qualidade.

Esses modelos fornecem um roteiro útil para o trabalho de engenharia

de software.

PRINCIPAIS MODELOS DE CICLO DE VIDA :

- Modelo Codifica-Remenda;

- Modelo Sequencial Linear (Cascata);

- Modelo Incremental;

- Modelo RAD;

- Modelo Prototipação;

- Modelo Espiral;

- Modelo Unificado;

- Modelo PRAXIS;

- Modelo Sala Limpa.

O MODELO DE CICLO DE VIDA PROCESSO É ESCOLHIDO COM BASE:

- Na natureza do projeto e da aplicação ( tipo de software );

- Nos métodos e ferramentas a serem utilizados;

- Nos controles e nos produtos intermediários e finais a serem
entregues.

LEVANTAMENTOS DE NECESSIDADE :

Entendimento e levantamento das necessidades da área do negócio.

- Analise :

Identificação e avalição das alternativas sistêmicas que atendem aos

requisitos.

- Projeto :

Definem as características técnicas relacionadas a construção como

arquitetura e o banco de dados.

- Desenvolvimento :
Inclui a codificação e os testes de novo sistema.

- Implantação :

- Consiste em transferir a aplicação do ambiente de desenvolvimento para o

ambiente de produção.

- Manutenção :

- Atividades relacionadas a correções e/ou inclusão de novas funcionalidades

após o sistema estar em produção.

MODELO DE CODIFICADA-REMENDA

É o modelo de ciclo de vida mais caótico.

Parte de uma especificações simples ou uma reunião para iniciar a

codificação, fazendo correções á medida que surge os defeitos.

Não há a separação de papeis e todos fazem todas as atividades.

Ainda é utilizado nos dias atuais.

MODELO CASCATA (WATERFALL)

Engenharia de Sistemas :

Envolve a coleta das necessidades dos usuários.

Defina-se :

- Os requisitos de negocio;

- A avaliação de sistemas atual em uso, se existir.

- Elementos de software e hardware necessários.

Analise :

Concentra-se no detalhamento do “o que” deve ser feito.

DESIGN (PROJETO)

- Define o “como” a aplicação deve ser feito.

- Envolve a definição da arquitetura de software, do bando de dados e das

características visuais.

Codificação :

- Tradução dos requisitos para uma linguagem de programação.

Testes :

- Verifica se a aplicação esta de acordo com a sua especificação.

Manutenção :

- Envolve as alterações no sistema relacionada aos erros, as evoluções de

negócio ou as evoluções de negocio ou as evoluções técnicas.

Principais Dificuldades :

- Os projetos nem sempre são sequenciais e as mudanças sempre trazem

problemas;

- O produto somente é visível no final de todo o ciclo.

Quando Utilizar :
- Projetos com requisitos bem definidos;

Projetos pequenos com duração de, ate 2 meses.

INTERATIVIDADE 2 :

RESPOSTA CERTA É : c) o produto e so visto no final.

MODELO INCREMENTAL

Divide o desenvolvimento com software em incrementos (que são partes do

sistema) que “Independem” uns dos outros .

Cada sequencia linear produz um parte do software. O processo se repede

ate que o produto esteja completo.

O incremento inicial é chamado de núcleo do produto. Isto que dizer que os

requisitos básicos devem ser satisfeitos logo no inicio do projeto.

MODELO INCREMENTAL – QUANDO UTILIZAR ?

Para sistemas que podem ser divididos em módulos.

Para sistemas com muitas alteração de requisitos.

Quando o usuário necessita de utilizar uma parte do produto antes do final de

um projeto.

Quando há um prazo de entrega que não pode ser modificado.

Vantagens :

- Entregas parciais facilitam a validação do cliente;

- Feedback consiste aumenta a qualidade;

- Cada incremento é uma parte de software utilizável.

Desvantagens :

- Cliente pode não aceitar a divisão em módulos.

MODELO RAD (RAPID APPLICATION DEVELOPMENT)

É incremental e contem um ciclo de desenvolvimento curto (em média de 60 a

90 dias).

Construção baseada em componentes.

Pode ser dividido entre as varias equipes RAD e, ao final, integra para formar
o todo.

Quando Utiliza ?

As restrições de tempo devem ser (em media de 60-90 dias).

Se a aplicação de software pode ser modularizada e cada função principal

possa ser completada em menos de 3 meses.

Cada função principal pode ser tratada por uma equipe distinta e, depois,
integrada para formar um todo.

VANTAGENS :

- Ciclo curto de desenvolvimento;

- Usa a prototipação interativa e viva;

- Aumenta o reuso do código.

DESVANTAGENS :

- Não indicado para projetos grandes e complexos;

- Não aplicado a projetos com alto risco técnico.

MODELO DE PROTOTIPAÇÃO

É um modelo evolucionário. Pode ser usado por qualquer dos demais

modelos. Utilizado para identificar e validar os requisitos. Permite visualizar
como o sistema ficará quando estiver pronto.

QUANDO UTILIZAR ?
Quando os requisitos estão mal definidos e ou difíceis de serem compreendidos. Um
meio de redução de risco. Ao permitir que o usuário visualize como vai ficar antes de
estar prontos. Pode ser usado em qualquer tipo de sistema na fase de captura dos
requisitos. Depois pode continuar com outros modelos ao decorrer de
desenvolvimento.

VANTAGENS :

- Reduz o numero de mudança;

- Aumenta a qualidade;

- Pode reduzir o tempo de desenvolvimento.

DESVANTAGENS :

- O cliente acha que o produto esta pronto;

- O projetista pode incorporar as soluções inadequadas.

INTERATIVIDADE :

RESPOSTA CERTA É : b) Divide o software em partes menores.

MODELO ESPIRAL

Engloba a natureza interativa do modelo de Prototipação com os aspectos do

modelo Cascata e de analise de risco . Cada loop representa uma fase do processo
de software. Onde cada loop pode estar relacionado á viabilidade do sistema. O
próximo loop, á definição de requisitos.

O próximo loop, ao projeto e assim por diante. A cada ciclo são produzidas versões
cada vez mais completas do software.

Para softwares de grande porte. Para software que possuem riscos no seu
desenvolvimento. Com o uso de prototipação, tem-se melhor conhecimento de
requisito do sistema.
VANTAGENS :

- É uma alternativa ao ciclo cascata;

- Primeiro modelo a incluir a analise de risco;

- Permite uma maior interação com o cliente.

DESVANTAGENS :

- Difícil converter o cliente que uma abordagem “evolutiva” é melhor;

- Exige experiencia na avaliação de risco e no uso do modelo.

PROCESSO UNIFICADO

- Baseado em casos de uso

- Centrado em arquitetura.

- Modela o software utilizando UML.

- Desenvolve o software interativamente.

- Gerencia os requisitos.

- Verificação continua da qualidade.

VANTAGENS :

- Tolerância ás mudança de requisitos;

- Elementos de um software são integrados progressivamente;

- Incorpora, formalmente, a gerencia do projeto ao ciclo.

DESVANTGENS :

- Cliente não aceita o processo interativo;

- complexidade de suas tarefas e seus fluxos;

- indispensáveis que os profissionais sejam capacitados no processo.

RUP (PROCESSO UNIFICADO RACIONAL)

Apresenta 4 fases :

Concepção ou iniciação, elaboração, construção e transição disciplinas :

São 10 atividades que viriam de intensidades conforme a fase. Dão origem aos
artefatos do projeto.

PROCESSO PRAXIS

Tem como objetivo dar suporte ao treinamento em engenharia de software á

implantação de processos em organização. É baseada na experiencia do prof. Wilson
de Paula Filho. Baseia-se em : CMMI, UML, UP e nos padrões do Eletric Eletronic
Enginnering (IEEE) para a engenharia de software.

Fornece suporte para projetos realizados individualmente ou por pequenas equipes,

com duração de seis meses a um ano. Abrange requisitos, analise, desenho, teste,
implementação, quando métodos gerenciais, como gestão de requisitos, gestão de
projetos, garantia de qualidade e gestão de configuração. Propõe um ciclo de vida
composto por fases. Gera artefatos ( DOCUMNETOS E MODELOS ).

PROCESSO CLEAN ROOM (SALA LIMPA)

É uma aplicação pratica e matemática e estatística para reduzir software de alta

qualidade. Aplica fortemente a prevenção de erros. Utiliza os métodos de
especificação precisos, chamadas de especificações formais. A especificação formal é
complexa e trabalhosa.

QUANDO UTILIZAR ?

- Normalmente utilizada na produção que trazem risco á perda de vidas humanas.

EXEMPLOS : controle de trens, metro, aviões, usinas nucleares.

VANTAGENS :

- Alta qualidade
- baixo numero de erros.

PROBLEMAS :

- Processo muito complexo;

- Requer conhecimento matemático;

- Produtividade é menor.

INTERATIVIDADE 4

RESPOSTA CERTA É : d) é baseado em casos de uso centrado em arquitetura.

UNIDADE 3

Em 2001, kent beck e 16 outros notáveis desenvolvedores, produtores e

consumidores de software, conhecido como Aliança ágil, assinaram o manifesto para
desenvolvimento ágil de software.

Valores :

Indivíduos e interações em vez de processos e ferramentas. Software funcionando em

vez de documentação abrangente, colaboração do cliente em vez de negociação de
contatos. Reposta as modificações em vez de seguir um pleno.

Princípios :

1 – Modificações de requisitos são bem-vindo.

2 – Entrega de software funcionando frequentemente.

3 – Pessoal de negócios e desenvolvedores trabalhando juntos.

4 – indivíduos motivados.

5 – Conversa face a face para levantar informações.

6 – Software funcionando com medidas de progresso.

7 – Ritmo constante de desenvolvimento sustentável.

8 – Excelência técnica.

9 – Simplicidade.

10 – Equipes auto-organizadas.

11 – Equipes reflete sobre como se tornar mais efetiva, então sintoniza e ajusta
adequadamente seu comportamento.

Princípios básicos :

- Simplicidade

- comunicação

- Feedback

- Coragem

EXTREME PROGRAMMING (XP)

1 – Processo de Planejamento (*Planning Gamer*)

2 – Releases Curtos

3 – Metáfora

4 – projeto (design) simples

5 – testes

6 – refactoring

7 – gerenciar a qualidade

8 – programação em Pares

9 – propriedade coletiva do código

10 – interação continua
11 – semana de 40 horas

12 – on-site customer (cliente sempre presente)

DESVANTAGENS DO PROCESSO

Não haver nenhuma documentação do projeto.

Trabalhar somente com recursos de nível sênior é mais caro difícil

Difícil controle para projetos grandes

Software é construído para o “agora”

Mudança cultura.

INTERTIVIDADE

RESPOTA CERTA É : e) entregas continuas

SCRUM

É um processo incremental para o desenvolvimento de qualquer produto de

software, é um processo incremental para gerenciamento de qualquer projeto, formal
e tem passos predefinidos, pouca flexibilidade de mudança.

Componentes

Processos : reunião de planejamento, reunião diária, reuniões de revisão e de lições

aprendidas.

Ferramentas : quadro Kanban, estórias, gráficos de controle.

Pessoas : Scrum master, Product Owner e time de desenvolvimento.

Cultura: time multidisciplinar, time auto gerenciável, entrega de valor, cliente do time,
entregas continuas e colaboração.
MINHA PESQUIÇA

A Engenharia de Software 2 é uma disciplina que se concentra em

abordar aspectos avançados do desenvolvimento de software,
envolvendo conceitos, práticas e técnicas para projetar, construir e
manter sistemas de software de qualidade. Alguns dos itens
importantes relacionados a Engenharia de Software 2 incluem:

Modelagem de Software: A Engenharia de Software 2 enfatiza a

importância de criar modelos abstratos para compreender e
representar os diferentes aspectos do sistema de software. Isso
envolve o uso de diagramas, como diagramas de classes,
diagramas de sequência e diagramas de atividades, para capturar
requisitos, arquitetura, comportamento e interações do sistema.

Arquitetura de Software: A definição de uma arquitetura de software

adequada é um aspecto crítico na Engenharia de Software 2. Isso
envolve a seleção de padrões de projeto, estilos arquiteturais e
tecnologias apropriadas para garantir a escalabilidade, a
manutenibilidade e a reutilização do software.

Gerenciamento de Projeto: A Engenharia de Software 2 aborda

tópicos avançados relacionados ao gerenciamento de projetos de
desenvolvimento de software. Isso inclui técnicas de estimativa de
esforço, planejamento de projetos, rastreamento de progresso,
identificação e gerenciamento de riscos, alocação de recursos e
coordenação de equipes de desenvolvimento.

Qualidade de Software: A qualidade do software é uma

preocupação importante na Engenharia de Software 2. Isso envolve
a aplicação de práticas de garantia de qualidade, como revisões de
código, testes automatizados, testes de desempenho e
monitoramento da qualidade do software em produção.

Engenharia de Requisitos: A Engenharia de Software 2 aborda

técnicas avançadas para a elicitação, análise e documentação de
requisitos de software. Isso inclui a identificação de requisitos não
funcionais, a definição de requisitos em níveis mais granulares e a
validação contínua dos requisitos ao longo do ciclo de vida do
desenvolvimento de software.

Gerenciamento de Mudanças: A Engenharia de Software 2 lida com

a gestão eficaz de mudanças no software. Isso envolve o uso de
sistemas de controle de versão, práticas de integração contínua e
estratégias de implantação para lidar com as mudanças no código,
requisitos e ambiente de desenvolvimento.
Desenvolvimento Ágil: A Engenharia de Software 2 pode incluir
abordagens ágeis de desenvolvimento, como Scrum ou Kanban,
que promovem a colaboração, a entrega contínua de software
funcional e a adaptação aos requisitos em constante mudança.

Esses são apenas alguns dos itens importantes relacionados à

Engenharia de Software 2. A disciplina abrange uma ampla gama
de tópicos e continua a evoluir à medida que novas tecnologias e
práticas de desenvolvimento surgem.