Prof. Doutor

Rogério Patrício Chagas do Nascimento

Professor Associado do Departamento de Computação (DCOMP)/UFS

Assessor do Reitor para Cidades Inteligentes Diretor Científico da EATIS.org

rogerio@ufs.br

GpESGrupo de Pesquisa em Engenharia de Software

Planejamento de Projeto de SW

Lecture 2

Sumário

▪ Introdução– O quê é?

– Quem faz?

– Porquê é importante?

– Qual é o produto?

– Como saber se está bem feita?

▪ Âmbito do SW

▪ Recursos do SW

▪ Plano de Projeto do SW

2

Introdução (I)

▪ O quê é?– O planejamento abrange

▪ Estimação

▪ Planejamento temporal e monitorização

– Diagrama de Gantt

▪ Análise e gestão de riscos

▪ Garantia da qualidade e gestão da configuração

▪ Quem faz?– Gestores de Software

3

Introdução (II)

▪ Porquê é importante?– Não se pode construir uma casa sem sabermos quanto vai custar

▪ Qual é o produto?– o Plano de Projeto de SW que contém:

▪ Tabela com as tarefas de gestão a realizar– Diagrama de Gantt

▪ Funções (ou Classes) a implementar

▪ Custo, esforço e tempo requerido para todas as tarefas (e para cada uma individualmente)

▪ Lista com os recursos requerido para o projeto

▪ Como fazer bem?– Enfoque sistemático com dados históricos sólidos

4

▪ Entrevista preliminar entre o Cliente e o Analista (engenheiro de sw)– após definida a especificação do SW

▪ Perguntas de contexto livre– Quem utilizará a solução?

– Qual o benefício econômico?

– Alternativas?

– Qual o “resultado correto”?

– Quais os possíveis problemas a confrontar?

– Qual o ambiente de utilização?

– Quais as limitações de rendimento?

5

Âmbito do SW- Obtenção da Informação Necessária

▪ Descreve o controle e os dados a processar, a função (ou Classe), a performance, as restrições, as interfaces e a confiabilidade

▪ são refinadas as funções (ou Classes) descritas na declaração do âmbito para detalhar seus atributos e métodos antes de se fazer a estimação– este refinamento é realizado durante n iterações (…)

▪ As considerações de performance abrangem os requisitos de tempo de resposta e processamento

▪ As restrições identificam os limites do software originados pelo hardware, e outros sistemas

6

Âmbito do SW

▪ Tecnologia– É tecnicamente factível o produto?

▪ Financeira– A empresa pode assumir os custos envolvidos?

▪ Tempo– Pode fazer-se o projeto antes do que a concorrência?

– Concluir sem atrasos?

▪ Recursos– A organização tem recursos suficientes?

▪ pessoal, tecnologia e ferramentas de apoio necessárias, licenças de utilização, formação, etc.

7

Âmbito do SW- Viabilidade

▪ Recursos Humanos

– Determinar bem os papéis para as respectivas especialidades

▪ Item mais importante!

▪ Gerar relatórios de Pessoa x Tarefas x Datas de Execução

▪ Recursos de Software

– Componentes já desenvolvidos

– Componentes experimentados

– Componentes com experiência parcial

– Componentes novos

8

Recursos (I)

Se há componentes desenvolvidos ou experimentados que satisfazem os requisitos, utilize-os mesmo que tiver que os comprar…

Analise bem o uso de componentes que tenha apenas uma experiência parcial!

▪ Recursos do Ambiente de Desenvolvimento– Necessidades de outros produtos associados

▪ Por exemplo, um software para desenho avançado de páginas Web requer uma ferramenta de apoio para edição de imagens ou uma assinatura digital em alguma fase do desenvolvimento

9

Recursos (II)

Plano de Projeto de SW- Objetivos

▪ Comunicar o âmbito e os recursos aos gestores do software, pessoaltécnico e ao cliente

▪ Definir os riscos e sugerir técnicas de combate aos riscos

▪ Definir os custos e a planejamento temporal para a revisão da gestão

▪ Proporcionar um enfoque geral do desenvolvimento do software para todo o pessoal relacionado com o projeto

▪ Descrever como se garante a qualidade e se geram as mudançasnecessárias

10

Plano de Projeto de SW

Plano de Projeto:

Introdução

Estimação / Métrica

Gestão de Riscos

Planejamento Temporal

Organização de Pessoal

Controle de Qualidade

11

Seção Extra

▪ Planos de Projetos de Software mais utilizados nas Universidades– Pressman

– Somerville

– Frailey

▪ Planos de Projetos de Software mais utilizados nas Indústrias– Ao invés de propor um plano de projeto, a indústria foca em técnicas para

estimação de riscos, custos e duração de projetos propostos por Pressman eSommerville.

12

Seção Extra- Comparação dos Planos de Projetos de Software nas Universidades

Autor Plano de Projeto de Software

Pressman 1. Introdução2. Estimativa do Projeto

3. Gerenciamento dos Riscos4. Cronograma do Projeto

5. Organização do Time6. Mecanismos de Controle e Rastreio

7. Apêndices

Sommerville 1. Introdução2. Organização do Projeto

3. Análises dos Riscos4. Requisitos de Software e Hardware

5. Divisão das Tarefas6. Cronograma do Projeto

7. Mecanismos de Monitoramento e Relatórios

Frailey 1. Estrutura de Divisão das Tarefas2. Estimativa

3. Alocação de Agenda4. Progresso de Monitoramento

5. Exibir Progresso6. Revisão

13

Seção Extra- Comparação de Alguns Planos de Projetos de Software na Indústria

Autor / Título do Artigo Plano de Projeto

de Software

Técnica

Albadarneh et al.

Risk management in Agile software

development: A comparative study

Gerenciamento de

Riscos

Estudo comparativo do gerenciamento de

riscos em diferentes metodologias ágeis

Logue e McDaid

Agile release planning: Dealing with

uncertainty in development time and

business value

Planejamento de

Lançamento

Método estatístico para seleção do conjunto

ideal de tarefas a serem desenvolvidas

Chang

Applying resource capability for

planning and managing contingency

reserves for software and

information engineering projects

Gerenciamento de

Recursos de

Contingência

Uso de uma fórmula de capacidade de

recursos para indicar quanto e quando os

recursos devem ser usados

14

Plano de Projeto de SW- Observações Finais

▪ o plano não é um documento estático

▪ a equipe do projeto deve consultar o plano repetidas vezes para atualizar os(as)..– Riscos

– Estimações

– Planejamento

– e informações relacionadas..

15

Materiais Extras (I)- Artigos

– CHANG, P. H. Applying resource capability for planning and managing contingency reserves for software and information engineering projects. In 2012 IEEE International Conference on Electro/Information Technology, Indianapolis, IN, USA, May 6-8, 2012, pages 1–8, 2012.

– FRAILEY, D. J. Teaching project planning with no project. In IEEE 29th Conference on Software Engeneering Education and Training, CSEEandT 2016, pages 37–45, 2016.

– GAROUSI, V.; PETERSEN, K.; OZKAN, B. Challenges and best practices in industry-academia collaborations in software engineering: A systematic literature review. Information and Software Technology, 2016.

– LOGUE, K.; MCDAID, K. Agile release planning: Dealing with uncertainty in development time and business value. In Proceedings - Fifteenth IEEE International Conference and Workshops on the Engineering of Computer-Based Systems, ECBS 2008, pages 437–442, 2008.

– MALHOTRA, R. and CHUG, A. Comparative analysis of agile methods and iterative enhancement model in assessment of software maintenance. In Proceedings of the 10th INDIACom; 2016 3rd International Conference on Computing for Sustainable Global Development, INDIACom 2016, pages 1271–1276, 2016.

– Nascimento, F. M. et al. Software Project Plan for Mobile Games Development : A Quasi-Systematic Review. 2016.

▪ https://www.sbgames.org/sbgames2017/papers/INDUSTRIA/FULL_PAPERS/175455_versao_preliminar.pdf

– PRESSMAN, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, Inc., New York, NY, USA, 7 edition, 2010.

16

Materiais Extras (II)- Livros (Leitura Complementar)

17

próxima aula prática…

Bons caminhos!

Obrigado pela atenção! Thanks for listening! Merci pour votre attention!

rogerio@dcomp.ufs.br

@Patricium