INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

Utilização de Ferramentas para Análise e

Implementação de S.I.– Aula 01

Docente: Camilo Amarcy

Email: Camilo@Amarcy.com
Cell: +258823032445
BBM: 2095A1FA
 Temas do Capítulo

• Descrição dos objectivos;

• Problemas no Desenho de S.I.;
• Factores Fundamentais do Processo;
• Questões de controlo;
• Aspectos preliminares;
• Organização da actividade

Camilo Amarcy
 Objectivos do Capítulo

Questões para os Especialistas

de DSI

• Quem precisa de um processo

para gerenciar o desenvolvimento
de software?

• O que é essencial a um processo

de software?

• Existe um roteiro mínimo para

gestão do processo de
desenvolvimento de software?

Camilo Amarcy
 Problemas no DSI

Constatações do Processo

• Inabilidade para gerir o escopo — fazer mais do que se

pode;

• Inabilidade para capturar requisitos — dificuldade em

gerir mudanças;

• Inabilidade para estimar — muito optimismo ao estimar

cronogramas;
• Deficiência no projecto — alcança-se os requisitos, porém com problemas ao
projectar o sistema;

• Deficiência para produzir produtos de qualidade — o produto apresenta muitas

falhas devido ao pouco teste e desvios no procjeto;

• Desempenho abaixo do esperado; Problemas descobertos tardiamente;

Camilo Amarcy
 Problemas no DSI

Possíveis causas das falhas

• Gestão de requisitos precária;

• Comunicação ambígua e pouco precisa;

• Arquitetura frágil do produto;

• Inconsistências não percebidas entre

requisitos, projeto e código;

• Teste insuficiente; Pouca automação;

• Avaliação subjetiva do status do projeto;

• Redução de risco deixada para muito depois;

• Propagação não controlada de mudanças;

Camilo Amarcy
 Problemas no DSI

Desvio das barreiras do DSI

• O entendimento dos problemas existentes no

desenvolvimento de software é chave para se
entender a importância de se fazer uso de
algum processo;

• É importante notar que, se não existe nenhuma

conduta para desenvolvimento, será inútil partir
em busca de soluções para os problemas;

• Ao identificar as causas dos problemas, a via do

processo poderá eliminá-los, introduzindo
ferramentas para automação de actividades e
treinando as pessoas
Camilo Amarcy
 Factores Fundamentais do Processo

Factores essenciais do Processo

• Possuir uma visão;

• Aplicar uma arquitetura;

• Ter um plano e condutas de avaliação;

• Identificar e gerenciar riscos;

• Gerar e acompanhar resultados

(artefatos);

• Codificar e testar de forma iterativa

(visibilidade);

• Ser adaptável;
Camilo Amarcy
 Factores Fundamentais do Processo

Possuir uma Visão

A visão captura a essência dos requisitos:

• Quais são os termos chaves? (glossário)

• Qual problema se deseja resolver?

• Quem são os clientes? quais são as demandas

deles?

• Quais são as funcionalidades do produto?

• Quais são os requisitos funcionais? (use cases)

• Quais são os requisitos não funcionais?

• Quais são as restrições/limites do projeto?

Camilo Amarcy
 Factores Fundamentais do Processo

Aplicar uma Arquitectura

A arquitetura organiza ou estrutura as

partes chaves que devem compor o
software:

• Quais são as principais partes ou

componentes?

• Como fazê-las funcionar de forma

integrada?

• Já existe algum ambiente onde tais

componentes devam ser adicionados?

Camilo Amarcy
 Factores Fundamentais do Processo

Ter um Plano e Conduta de Avaliação

• Em projetos de baixa complexidade o plano pode

ser meramente um parágrafo, porém deve trazer
todas as informações necessárias ao gerenciamento
do projeto;
• Por exemplo: “ao final de cada dia os conteúdos do
diretório do projeto devem ser compactados, datado, copiados
num disco e colocado em local seguro”

Identificar e Gerir Riscos

• Listar os riscos, em ordem decrescente prioridade,

identificando os eventos negativos que eles podem
gerar;

• Definir condutas para superação dos riscos;

Camilo Amarcy
 Factores Fundamentais do Processo

Gerar e acompanhar resultados

(artefatos)

• Comunicar os resultados parciais de cada

atividade na forma de artefatos é uma boa
conduta para qualquer projeto

Codificar e testar de forma interativa

• “Quanto mais cedo você tropeçar, mais tempo você

terá para se recuperar e buscar a meta”

Ser adaptável

• Processo não deve ser seguido às cegas, ele

deve ser adaptado para atender as
necessidades do projeto e da organização

Camilo Amarcy
 Questão de Controle

Existirá uma formula mágica?

• Sim. Para quem nunca aplicou um

processo ao desenvolver software, a chave
para o sucesso é começar pequeno,
implementando apenas o essencial e, então,
avançar gradativamente

• Pequenos projectos, particularmente, são

bem servidos por processos light que
permitem ao grupo gastar a maior parte do
tempo com o desenvolvimento do
software, sem muito overhead administrativo

• Em geral, é importante não incluir

atividades e artefatos que não sejam
claramente justificados
Camilo Amarcy
 Aspectos Preliminares

Definição do projecto

• Pessoas envolvidas;
• Projeto a ser
desenvolvido;
• Produto esperado pelo
cliente;
• Processo a ser
implantado;
• Ferramentas de apoio;

Outros aspectos

• Duração;
• Local de trabalho;
• Fontes de recursos;

Camilo Amarcy
 Aspectos Preliminares

Preparação Importante

Visão do projeto:

• 5 pessoas
• Baixa complexidade
• Cliente com visão clara do resultado
esperado
• Motivação e disciplina são buscados

Outros aspectos:

• Duração máxima de cada iteração -

UM MÊS
• Pouca familiaridade com as
ferramentas
• Outras actividades em paralelo
Camilo Amarcy
 Aspectos Preliminares
Caminho para Preparação

• Toda a documentação dos artefatos devem ser mantidas exclusivamente através

de páginas Web do projeto. Todos os templates para o projeto podem ser gerados,
inicialmente, como “versões iniciais” das páginas web;

• Apenas aquelas actividades que contribuem diretamente para geração dos

artefatos são consideradas como relevantes e parte integrante do roteiro de
processo sugerido para o Projeto;

• Controle de Versões não seria um artefato essencial para este tipo de projeto,
porém, vamos considerar um mínimo de controle.

• O Status Assessment e Change Request, por exemplo, poderá ser gerenciado

informalmente através de anotações e lembretes em post-it

• Todos os artefatos devem ser revisados informalmente por no mínimo uma

segunda pessoa, em geral, pelo líder dos programadores, que aprova o artefato
antes de considerá-lo OK

Camilo Amarcy
 Aspectos Preliminares

Formato do Projecto – Parte 1

Lista Riscos iniciais do projeto devem ser identificados. A lista de riscos

de Riscos é mantida pelo Gerente de Projeto numa planilha localizada em:
projeto /gestão/riscos.xls, por exemplo
O Plano de Desenvolvimento de Software é gerenciado como
Plano de segue. O orçamento e o cronograma são gerenciados através de
Desenvolvimento arquivos do MS Project e armazenados em projeto
de Software /gestão/cronograma
Outros aspectos podem ser colocados na página Web do projeto.
Plano de Duas iterações serão desenvolvidas, cada uma com duração de
Iterações UM mês

Plano de Deve ser descrito no Plano de Desenvolvimento. Por exemplo,

Aceitação do mínimo de testes necessários, existência de help on-line, etc
Produto
Ao final de cada iteração, o grupo deverá se encontrar para
discutir sobre o status do projeto e fazer um brainstorming acerca
Status da de melhorias. O objetivo é capturar lições e aprendizagens.
Avaliação O gerente de projeto deverá enviar um e-mail sumarizando o
status do projeto para o grupo e clientes.

Camilo Amarcy
 Aspectos Preliminares

Formato do Projecto – Parte 2

Desenvolvimento Pode ser acompanhado através da página Web do Projecto

Templates Mantidos na página Web

específicos
Guias Documentos dos projectos anteriores ou a bibliotéca do
projecto
As ferramentas de suporte para a gestão do projecto são
Ferramentas padrões do Rational (Requisite Pro, Rose, SoDA, Test,
ClearCASE)

Camilo Amarcy
 Organização da Actividade
Definição de Papéis

O projeto envolve 5 pessoas,

que deverão assumir papéis
bem definidos (exemplo de um
projecto de programação):

• Gestor do projeto;
• Líder de Programação;
• Programador

Camilo Amarcy
 Organização da Actividade

Posição vs. Actividades

Posição no
Actividade/Papel
Projecto
 Gerente Projeto
 Eng. do Processo
Gerente de
 Gerente Entrega
Projeto
 Revisor Requisitos
 Revisor da Arquitetura
 Analista Sistema
 Especificador Requisitos
 Projetista Interface Usuário
Líder dos
 Arquiteto Software
Programadores
 Revisor Projeto; Eng. de Processo
 Especialista Tools; Gerente Versão
 Gerente Controle Mudanças
 Projetista; Implementador
 Revisor Código
Programador
 Integrador; Projetista Teste
 Testador
Camilo Amarcy
 Organização da Actividade
Modelação do Negócio

• Todo projeto demanda alguma

forma de modelagem do
negócio.

• Neste caso, deve ser bem

simples. A equipe deve gerar
algumas considerações acerca
da relevância deste projecto
para o mercado

Camilo Amarcy
 Organização da Actividade
Modelação dos Requisitos
Artefatos Conteúdo
Visão As principais funcionalidades do sistema. O RequisitePro pode ser usado
para coleta e edição dos requisitos
Especificações Requisitos suplementares devem abordar requisitos que não são diretamente
Suplementares mapeados nos use cases, tais como:
(requsisitos  Padrões e protocolos seguidos
não funcionais)  Atributos de qualidade (usabilidade, confiabilidade, desempenho, etc)
 Outros requisitos (SO, restrições do ambiente, etc)
Glossário Define os termos importantes usados no projeto
Modelo de Atores e use cases mais importantes que foram identificados e o fluxo de
Use-Cases eventos. Diagramas feitos usando o Rose são as descrições mais formais
(Atores, Use oriundas dos use cases
Cases)

Camilo Amarcy
 Organização da Actividade
Análise e Projecto
Iterações O seu Projeto poderá fazer uso de protótipos arquiteturais executáveis
(iterações) para explorar as funcionalidades críticas, de froma a minimizar
riscos. A cada iteração refinamentos são feitos para minimizar riscos.
Documento Uma descrição da arquitetura deverá descrever os use-cases arquiteturalmente
da Arquitetura mais significativos (visão do use-case): identificando os mecanismos chaves e
do Sistema elementos do projeto (visão lógica) e definindo a visão do processo e da
forma de entrega das funcionalidades do produto.
Modelo do O modelo do projeto deverá emergir de algumas reuniões de brainstorming
Projeto (e nas quais os desenvolvedores podem fazem uso de cartões (post-it) para
todos os anotações rápidas (diagramas feitos à mão e detalhes do projeto). O modelo
artefatos do projeto é uma abstração da implementação do sistema, envolve artefatos
envolvidos) tais como: diagramas de classes, definição de subsistemas, interfaces,
protocolos, etc. O SoDA pode ser usado para os relatórios do modelo de
projeto.

Camilo Amarcy
 Organização da Actividade
Implementação
Modelo O projeto deverá produzir duas iterações arquiteturais executáveis
de de forma a explorar todas as funcionalidades críticas modeladas. O
Implementaçã modelo de implementação deve definir: condutas de distribuição,
o testes, e formas d econtrole de versões.

“E todos os Todos os componentes gerados também devem ser descritos com

um mínimo de atributos (funcionalidades, desenvolvedor, testes,
artefatos
tempo consumido, etc). Ferramentas de Teste e para controle de
envolvidos, versões devem ser exploradas.
incluindo os
Componentes” Revisões informais do código devem ser realizadas - cada linha
deveria ser revisada por um segundo programador (o líder).
Qualquer falha que seja encontrada no código após esta fase deve
ser armazenada na forma de Change Request.

Camilo Amarcy
 Organização da Actividade

Teste
A documentação mais formal são os scripts de teste usados.

Modelo O revisor do código é responsável por assegurar que o teste

Teste seja suficiente e aconteça antes de sua integração.

(E todos os artefatos O líder de programação é responsável por assegurar que os

envolvidos) demais testes ( teste funcional, por exemplo), sejam executados no
nível do sistema.

Fazer das ferramentas de teste indicadas.

Camilo Amarcy
 Organização da Actividade

Entrega
Plano de Entrega O cronograma e atividades para entrega de cada iteração
devem ser incluídos no cronograma macro do projeto
Material de Treinamento Prever alguma forma de Help para o usuário.

Produto Prever a mídia na qual o produto deve ser entregue e

empacotado.
Indicador da versão Presente no Help Online.

Instalação dos Artefatos Algum template de instalação presente no Help Online.

Material de Suporte ao Presente no Help Online. Pode também estar presente em

Usuário página Web através de FAQs.

Camilo Amarcy
 Organização da Actividade

Controle de Versões – Parte 1

Neste projecto será aplicado um controle de

versões mais light, que garanta:

• Aos desenvolvedores saber como

submeter/integrar mudanças já
aprovadas;

• Algumas práticas chaves (backups

semanais);

• Armazenamento e avaliação de
solicitações de clientes internos ou
externos (change requests)

Artefatos gerados à mão devem ser

armazenados em alguma pasta
Fazer uso do ClearCase.

Camilo Amarcy
 Organização da Actividade

Controle de Versões – Parte 2

Plano de Deve seguir o mínimo especificado no slide anterior
Gestão de
Versões
A melhor forma de capturar defeitos é fazer uso de arquivos texto
Change armazenados em diretórios públicos.
Request
As solicitações dos clientes devem ser encaminhadas ao Gerente de
Projeto - que as mantém num arquivo texto separado, porém público.
Repositório Uma estrutura de arquivos de trabalho deve ser disponível na forma
do Projeto de diretórios comuns na rede, organizados como projeto/repositório,
por exemplo.
Espaço de A organização do espaço de trabalho deve ser descrita no Plano de
Trabalho Gestão de Versões.

Camilo Amarcy
 Dúvidas

.....

Camilo Amarcy