Resumo/Estudo – Engenharia de Software

Gerência de projeto de software

Tem a responsabilidade do projeto terminar no prazo com o custo previsto e a qualidade planejada.

1) Atividades do desenvolvimento de software:

  • Preparação de propostas de projeto;
  • Planejamento de projetos;
  • Estimar e monitorar custo de projetos (orçamento);
  • Controle e monitoração;
  • Seleção e avaliação dos recursos/colaboradores;
  • Apresentação (e relatórios) do projeto.

2) Processo de gerência de software

  • Planejamento;
  • Controle e monitoria;
  • Analise pós-morte.

Deve-se levar em consideração que esses 3 processos funcionam como um ciclo e aprendizagem contínua.

3) Fases da gerência de projetos

ScreenHunter_03 Apr. 25 01.01

3.1) Iniciação do projeto

Deve trazer uma visão geral do projeto,uma lista do que o sistema irá fazer. Levantamento e indicação de requisitos. Nesta parte é interessante também a realização da pesquisa de mercado/disponibilidade/aceitação de produto. Com isso,deve ser feito uma estimativa de orçamento.

Esta fase geralmente consiste em:

– Termo de abertura de projeto: autoriza o projeto;
– Declaração do escopo preliminar do projeto: aborda e documenta os requisitos do projeto e da entrega,os requisitos do produto, os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo.

3.2) Planejamento do projeto

Conforme contextos abordados no livro do CMMI, o propósito do planejamento do projeto é estabelecer e manter planos que definam as atividades do projeto.

Desenvolver um plano para o projeto:

– Caracterizar o contexto do projeto e da organização;
– Responsabilidades e stakeholders;
– Atividades: milestones(estado previsível onde algum relatório formal de progresso é apresentado para gerência,Ex: Análise de requisitos) e deliverables(resultados do projeto entregados ao cliente, Ex: Documento de requisitos);
– Estimativas de tamanho, esforço e custo;
– Definição das metas do projeto;
– Cronograma e orçamento;
– Riscos;
– Planejamento do controle de qualidade;
– Planejamento do controle e monitoração do projeto.

ScreenHunter_05 Apr. 25 01.15

3.3) Monitoramento e controle do projeto

– Acompanhar desenvolvimento do projeto;
– Verificar alinhamento com o plano;
– Identificar possíveis desvios;
– Tomar ações corretivas;
– Acompanhá-las até sua correção;

4) Técnicas de estimativa

4.1) Julgamento de especialista: especialistas utilizam sua experiência e intuição para predizer o custo.

4.2) Analogia: Custo é computado comparando o projeto com projetos semelhantes que já foram realizados anteriormente pela empresa.

4.3) Lei de Parkinson: O custo do projeto é o que há de recursos.

4.4) Pricing to win: O custo do projeto é o que cliente pode gastar.

4.5) Estimativa top-down: Começa no nívelmais alto do sistema e estima o custo para a funcionalidade do sistema.

4.6) Estimativa bottom-up: Começa no nível mais baixo do sistema e estima o custo para cada componente. Custo total é a soma destes custos.

5) Gerência de riscos

Tem como objetivo minimizar riscos durante o processo de desenvolvimento de software. Tem-se que ficar atento as atividades de alto risco pois podem impedir que se atinja as metas do projeto.

5.1) Análise de riscos

– Identificação de riscos;
– Fatores de riscos;

Exemplo: pessoal qualificado não está disponível, entrega demorada de uma nova ferramenta de software, etc..

– Avaliação e priorização do impacto de riscos.

5.2) Mitigação de riscos

1-Identificar os riscos(Ex: saída de um colaborador ou ficar doente..)
2-Prevenção: Todo o esforço que pode ser feito com maior ou menor eficácia para evitar a ocorrência do risco.
3-Contingência: Definição de estratégias e soluções alternativas no caso de ocorrência das situações de risco. Neste momento já aconteceu o acidente/risco.
3.1-Indicador ou gatilho de contingência: serve para disparar a contingência planejada.
4-Definição da probabilidade de ocorrência do risco
5-Impacto do risco(Ex: caso o arquiteto ficar doente, o projeto poderá ser cancelado.)

Exemplo de risco:
Risco: Tecnologias novas poderiam causar saída de pessoal da empresa;
Prevenção: Assessoria a ferramentas disponíveis, treinamento e motivação da equipe.

6) Controle e monitoramento

Controlar e monitorar o progresso e estado geral do projeto em andamento.

– Acompanhamento do tamanho atual de produto, esforço, cronograma e qualidade;
– Comparação dos valores atuais com as estimativas;
– Ajustes oportunos e informados ao plano do projeto de software;
– Atualização do plano.

6.1) Medidas típicas

– Despesas do orçamento;
– Cronograma-milestones;
– Esforço(homem-hora);
– Quantidade/tamanho de produto desenvolvido (e/ou modificado);
– Produtividade;
– Valor agregado.

7) Arquitetura em camadas

Tem como objetivo aumentar a coesão e reduzir o acoplamento e possui como característica a separação das classes por características assumidas dentro do contexto de uma aplicação.

7.1) Organização das classes

7.1.1) Limite(boundary): equivale ao View do padrão MVC.

– Entrada e saída de dados(telas, páginas..);
– Interação direta com os usuários do sistema;
– Também conhecidas como classes de fronteira.

7.1.2) Entidade(Entity): equivale ao Model do padrão MVC.

– Guarda informações em geral;
– Representam,usualmente, objetos persistentes.

7.1.3) Controle(Control): equivale ao Controller do padrão MVC.

– Controle de fluxo em geral(controla limites, entidades e outros controladores)
– Processamento (algoritmos), regras de negócio.

7.2) Como as camadas conversam entre si?

ScreenHunter_05 Apr. 28 01.48

7.3) Diagrama de robustez

Conforme Jean relata nos slides de sua aula, o diagrama de robustez preenche um espaço vazio entre o caso de uso e o digrama de sequência; não é um diagrama oficial da UML.

8) Padrão Model View Controller(MVC, lado técnico)

Conforme Engholm cita no livro, o padrão de arquitetura MVC separa as views e os controllers do modelo do sistema. Esse tipo de arquitetura permite que a interface da aplicação possa ser modificada sem preocupações com alterações na camada de lógica de negócio. Ela permite que aplicações web e não web possam acessar a mesma lógica de negócio.

Fonte: cleversonsacramento.com

Fonte: cleversonsacramento.com

9) Anotações e detalhes aleatórios referente aos assuntos abordados neste post

9.1) Casos de uso

Os pontos de caso de uso serve para medir o tamanho do sistema, chegando no esforço e consequentemente no custo.
Como classificar caso de uso: quantidade de passos no cenário, quantidade de telas para o caso de uso e quantidade de campos na tela.

Até a próxima.

Referências:

Slides da aula de Engenharia de Software ministradas na UNISUL pelo Dr. Jean Carlo Rossa Hauck.
Engholm Júnior, Hélio. Análise e Design: orientado a objetos. Novatec Editora, 2013.

Anúncios

Obrigado pelo comentário.

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s