Beruflich Dokumente
Kultur Dokumente
DESENVOLVIMENTO DE
SOFTWARE
autor
1 edio
SESES
rio de janeiro 2015
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara afonso de souza
Autor do original saulo frana amui
Projeto editorial roberto paes
Coordenao de produo gladis linhares
Coordenao de produo EaD karen fernanda bortoloti
Projeto grfico paulo vitor bastos
Diagramao bfs media
Reviso lingustica bfs media
Imagem de capa semisatch | dreamstime.com
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2015.
176 p. : il.
isbn: 978-85-5548-040-9
Sumrio
Prefcio
1. Conceitos Gerais e Atividades de
Processo de Desenvolvimento de Software 9
Objetivos 10
1.1Introduo
11
1.2 O que ? Para que serve?
11
1.2.1 Fases de um processo de Software 17
1.2.2 Atividades do Processo de Software 18
1.3 Problemas mais comuns
19
1.4 Anlise econmica e de requisitos
21
1.4.1 Anlise do problema
23
1.4.2 Avaliao e sntese
23
1.4.3Modelagem
24
1.4.4 Especificao dos requisitos e reviso
25
1.5 Especificao do Software 25
1.6 Desenho ou arquitetura do sistema de software 28
1.7 Codificao (Implementao)
30
1.8 Testes do produto
30
1.8.1O software e o teste de caixa preta
33
1.8.2O software e o teste de caixa branca
33
Atividades 34
Reflexo 35
Referncias bibliogrficas
36
2.2.1Artefatos
46
2.2.2 Documentao do cdigo-fonte
48
2.3 Manuteno de Software 51
2.3.1 Manuteno no estruturada
52
2.3.2 Manuteno estruturada
53
2.3.3Manutenibilidade
53
2.3.4 Reengenharia e engenharia reversa
54
2.4 Suporte e treinamento
58
2.5 Melhoria contnua
61
Atividades 64
Reflexo 65
Referncias bibliogrficas
66
69
Objetivos 70
3.1Introduo
71
3.2 CMM / CMMI
72
3.2.1 CMM (Capability Maturity Model)
72
3.2.1.1Maturidade
73
3.2.1.2Nveis
73
3.2.1.3 reas-chaves KPA
74
3.2.1.4 Nvel 1 Inicial
78
3.2.1.5 Nvel 2 Repetvel
79
3.2.1.6 Nvel 3 Definido
80
3.2.1.7 Nvel 4 Gerenciado
82
3.2.1.8 Nvel 5 Otimizado
83
3.3 ISO/IEC 15504 ou SPICE
84
3.4 ISO 12207 Processos do Ciclo de Vida do Software 86
3.5MPS.BR
88
Atividades 95
Reflexo 95
Referncias bibliogrficas
96
135
Objetivos 136
5.1 Processo unificado (UP)
137
5.2 Fases do processo
137
5.3 Ciclo de vida do processo
140
5.3.1 Fluxo de requisitos
142
5.3.2 Fluxo de anlise
5.3.3 Fluxo de projeto
5.3.4 Fluxo de implementao
5.3.5 Fluxo de teste
5.4 RUP (Rational Unified Process)
5.4.1 Contedo do RUP
5.4.2 Como adotar
5.4.3PRAXIS
5.5 Ferramentas CASE
5.5.1Histrico
5.5.2 Arquitetura de ferramentas
5.5.3 Integrao entre ferramentas
143
144
146
147
148
151
152
152
154
154
156
158
5.5.4 Taxonomia
159
5.5.5 Vantagens e desvantagens
162
5.5.6 Funcionalidades das ferramentas CASE
163
Atividades 167
Reflexo 168
Referncias bibliogrficas
169
Gabarito 169
Prefcio
Prezados(as) alunos(as),
O conhecimento dos Processos de Desenvolvimento de Software essencial
para o desenvolvimento e construo de um produto de software de qualidade.
Veremos que a qualidade de software est associada a seus processos e s boas
prticas de desenvolvimento.
Desde o seu incio, a rea de desenvolvimento de softwares encontra grandes desafios para obter sucesso nos projetos propostos destas, j que trata-se
de uma atividade complexa e cheia de fatores que influenciam as atividades de
desenvolvimento e, consequentemente, o xito do projeto de software. Desta
forma, o estudo na rea de Engenharia de Software trouxe uma srie de mtodos, processos, modelos e normas para que os profissionais desta rea pudessem ter o auxlio necessrio para saber lidar com estes desafios, presentes em
praticamente todas as etapas do processo de desenvolvimento.
Cada fase ou etapa do processo de desenvolvimento de software tem uma
infinidade de assuntos importantes e que foram estruturados nas diferentes
metodologias existentes. A documentao de software tambm algo que est
presente por todas estas etapas.
Ao longo destes captulos, voc poder conhecer e aprender muitas coisas
importantes sobre os aspectos que envolvem o desenvolvimento de um software e ver que, mesmo sendo uma atividade complexa, do ponto de vista do
gerenciamento do projeto, h diferentes meios e maneiras de realiz-la, com
adaptaes corretas e conhecendo bem os principais pontos que cada modelo,
mtodo e processo propem para as diferentes situaes.
Por fim, vale ressaltar que, embora estejamos abordando vrios pontos importantes ao longo do livro, h uma imensido de contedos, materiais e referncias bibliogrficas de praticamente todos os assuntos aqui tratados, valendo a pena pesquisar e estudar ainda mais os pontos de maior interesse e
necessidade em sua vida profissional.
Aproveite a leitura e os estudos para tentar transportar os conceitos aprendidos em sua vida prtica, ou observ-los em uso em empresas e nos ambientes
adequados.
Bons estudos!
1
Conceitos Gerais
e Atividades de
Processo de
Desenvolvimento de
Software
OBJETIVOS
Compreender os principais conceitos que envolvem as atividades de processo de desenvolvimento de software;
Conhecer os problemas mais comuns no processo de desenvolvimento de software;
Ter uma viso da anlise econmica e de requisitos de software;
Aprender sobre a especificao do software e desenho ou arquitetura do sistema de software;
Conhecer as atividades que envolvem a codificao ou implementao de software;
Conhecer os principais conceitos e atividades relacionadas aos testes.
10
captulo 1
1.1 Introduo
Desenvolver softwares uma atividade complexa e no poderia ser realizada
se no houvesse um conjunto de atividades, sequncias, devidamente organizadas e estruturadas em passos ou etapas bem definidas. Este conjunto de atividades considerado um processo e, quando o aplicamos em um contexto de
software, estamos lidando com os processos de desenvolvimento de software,
auxiliados pelas reas de conhecimento da Engenharia de software.
Quando o homem, ao longo de sua histria, precisou construir ou elaborar
grandes construes, a engenharia contribuiu para a melhoria dos processos,
encontrando os melhores recursos e otimizando as atividades por meios de
mtodos que foram amadurecendo cada vez mais, assim como podemos notar
na engenharia civil, na construo de grandes prdios ou grandes obras, onde
estas construes so dividas em etapas muito claras e com as suas peculiaridades e especificidades. Para a construo de softwares, estas prticas da engenharia tambm esto presentes quando notamos os processos utilizados e
as tcnicas aplicadas nas diferentes fases, envolvendo desde a sua concepo,
passando por modelagens do que ser construdo, pelo desenho do software,
pela discusso e anlise ainda no papel, para s ento, depois, partir para uma
fase especfica de codificao ou de implementao e, posteriormente, para a
etapa de testes, e assim serem entregues aos clientes ou usurios finais.
Veremos, ao longo dos prximos tpicos, maiores detalhes das principais
etapas que envolvem estes processos de desenvolvimento de software, conhecendo um pouco mais de detalhes sobre estes processos e das situaes que os
envolvem.
captulo 1
11
entende isso como oficial e tampouco os conhece. Estes processos podem ser
parcialmente transferidos para outras pessoas, por transmisso oral e por imitao, e isso um grande problema.
Em contrapartida, quando existe um processo definido e tem documentao detalhada sobre todos os seus aspectos importantes, por exemplo, o que
feito, quando, por quem, as coisas que usa e as coisas que produz, a organizao como um todo cresce.
Existem muitas formas de representao de processos definidos. Exemplos
de possveis formas so:
por uma sequncia de passos descritos em linguagem natural;
por tabelas nas quais cada linha corresponde a um passo do processo;
por representaes grficas, como os fluxogramas e notaes equivalentes, entre elas a UML.
Sem dvida, quando os processos so bem definidos, a maturidade das organizaes produtoras de software incrementada, pois permitem que a organizao tenha uma forma de trabalho padronizada e que pode ser repetida.
Desta forma, a capacitao das pessoas facilitada e torna o funcionamento
da organizao menos dependente de determinados indivduos.
Entretanto, os processos definidos no sero sinnimos de plena realizao. Processos rigorosamente definidos, mas no alinhados com os objetivos da
organizao, tornam-seimpedimentos burocrticos e no fatores de produo.
Vimos que para tornar uma organizao mais madura e capacitada realmente preciso melhorar a qualidade dos seus processos. Os processos no melhoram simplesmente por estarem de acordo com um padro externo, e sim
pela medida de quanto eles contribuem para que os produtos sejam entregues
aos clientes e usurios:
com melhor qualidade;
com menor custo;
e num menor prazo.
A ISO/IEC, 2008, tambm define processo como sendo um conjunto de atividades inter-relacionadas que podem transformar entradas em sadas. Estas
entradas so tambm conhecidas por requisitos do cliente ou at mesmo por
12
captulo 1
produtos intermedirios que so produzidos pelos processos ao longo do desenvolvimento de software. As sadas tambm podem ser estes produtos intermedirios, que sero utilizados por outros processos ou pelo produto de software final (COSTA, 2012, p. 9).
No mbito de desenvolvimento de software, processo e ciclo de vida de software esto diretamente relacionados. Assim, pode-se considerar que processo
de software est associado a um conjunto coerente de polticas, estruturas organizacionais, procedimentos, artefatos e tecnologias que so necessrios para
conceber, desenvolver, entregar e manter um produto de software (FUGGETTA,
2000); e ainda, de acordo com PAULK et al., 1993, a produtos associados, como
cdigo-fonte, manual, plano do projeto, casos de uso, casos de testes, etc.
(COSTA, 2012, p. 9).
Sommerville (2003) ainda define processo de software como um conjunto
de atividades e resultados associados que geram um produto de software. A
maioria destas atividades so executadas por engenheiros de software, sendo
que existem quatro atividades de processo fundamentais e comuns a todos os
processos de software. Ainda de acordo com Leite (2000), essas atividades so:
1. ESPECIFICAO DO
SOFTWARE
2. DESENVOLVIMENTO DO
SOFTWARE
3. VALIDAO DO SOFTWARE
4. EVOLUO DO SOFTWARE
SOMMERVILLE, 2003
captulo 1
13
14
captulo 1
O Processo de Software
O autor Silva (2006) cita uma considerao importante levantada por Fuggeta (2000)
e outra observao realizada por Rocha et al. (2001), nos respectivos trechos a seguir:
Uma importante contribuicao da area de pesquisa de processo de software tem sido
a conscientizacao de que o desenvolvimento de software e um processo complexo.
Pesquisadores e profissionais tem percebido que desenvolver software nao esta circunscrito somente a criacao de linguagens de programacao e ferramentas efetivas. O
desenvolvimento de software e um processo coletivo, complexo e criativo. Sendo assim,
a qualidade de um produto de software depende fortemente das pessoas, da organizacao e de procedimentos utilizados para cria-lo e disponibiliza-lo.
Dada a complexidade envolvida na definicao de processos de software, nao e uma
boa estrategia definir cada processo de projeto a partir do zero. Assim, apesar de cada
projeto ter suas caracteristicas proprias, e possivel estabelecer conjuntos de elementos
que devem estar presentes em todos os processos de uma organizacao. Esses elementos em comum possibilitam a formacao dos processos-padrao da organizacao, que,
por sua vez, podem ser especializados para determinadas classes de projetos dessa
organizacao. Processos-padrao e especializados podem, entao, ser instanciados em
processos de projeto, em uma abordagem de definicao de processos em niveis
15
Wazlawick, 2013, p. 31, apresenta algumas vantagens em definir o desenvolvimento de software como um processo, como pode-se ver nesta pequena
relao a seguir:
a) O tempo de treinamento pode ser reduzido: com processos bem definidos
e documentados, mais fcil encaixar novos indivduos na equipe do que quando no
se dispe deles.
b) Produtos podem ser mais uniformizados: a existncia do processo no garante a uniformidade na qualidade dos produtos, mas certamente uma equipe com
um processo bem definido tende a ser mais previsvel do que a mesma equipe sem
processo algum.
c) Possibilidade de capitalizar experincias: pode-se imaginar que um processo de trabalho bem definido poderia tolher o uso da criatividade dos desenvolvedores.
Contudo, isso no verdade, a no ser que a empresa tenha processos engessadores,
o que no bom. Um processo bem gerenciado deve ter embutidos mecanismos para
melhoria. Assim, se um desenvolvedor descobrir um meio de fazer as coisas de maneira
melhor do que a que est descrita no processo, devem haver meios para incorporar
essas alteraes.
16
captulo 1
1. ESPECIFICAO
DE REQUISITOS
de processos adotado para se desenvolver um software. Ser necessrio conhecer quais so as necessidades deste software, quais
so as restries e conhecer bem o domnio da aplicao.
2. PROJETO DE
SISTEMA
3. PROGRAMAO
(CODIFICAO)
o, que ir representar o controle do sistema, a lgica e as operaes de acordo com aquilo que fora descrito e levantado na fase de
projetos a partir dos requisitos.
Nesta fase so realizados os testes, a verificao do sistema checando se o produto desenvolvido ou seus componentes esto alinhados
4. VERIFICAO
E INTEGRAO
(VALIDAO)
5. MANUTENO E
EVOLUO
alterao que os requisitos venham sofrer aps o sistema ser colocado em produo. Esta fase tambm conhecida como manuteno e estas atividades podem sofrer tanto mudanas estruturadas
como no estruturadas.
captulo 1
17
18
captulo 1
4. Validao
a) Teste de Unidade e Mdulo: a realizao de testes para verificar a presena de erros e comportamento adequado a nvel das funes e mdulos bsicos do sistema.
b) Integrao: a reunio dos diferentes mdulos em um produto de software homogneo e a verificao da interao entre estes quando operando em
conjunto.
5. Manuteno e Evoluo
a) Nesta fase, o software entra em um ciclo iterativo que abrange todas as
fases anteriores.
Sendo assim, o produto final est associado s atividades de cada fase do
processo de desenvolvimento, que por sua vez so especificadas, detalhadas e
colocadas em uma ordem que auxilia e orienta os diferentes modelos de desenvolvimento de softwares.
CONEXO
Voc pode encontrar recursos completos para padres de processo no endereo eletrnico:
http://ambysoft.com/processPatternsPage.html
No livro de Engenharia de Software do conhecido e respeitado autor Pressman
(PRESSMAN, 2011, p. 58) h uma pergunta com uma resposta da Nasa. A pergunta:
Quais tcnicas formais esto disponveis para avaliar o processo de Software?. A resposta dada pela Nasa : As organizaes de Software apresentaram falhas significativas
quanto habilidade em capitalizar as experincias adquiridas nos projetos finalizados.
19
1. REQUISITOS DO
USURIO
2. REQUISITOS DE
SISTEMA
3. ESPECIFICAO
DE PROJETO DE
SOFTWARE
20
captulo 1
Zabeu et al. (2006) comenta que muitos problemas que envolvem as organizaes esto alm da falta de clareza dos requisitos ou da ausncia de testes
que que deveriam ser aplicados de maneira adequada e da inexistncia de capacitao do pessoal envolvido. As organizaes possuem problemas por uma
falta de gesto de processos, que caracterstica tpica da imaturidade em relao ao nvel de seus processos internos e que so bem conhecidos pela indstria. No entanto, a implementao de sistemas de gesto eficientes e corretos
com normas, como, por exemplo, da ISO 9000, ISO/TS 16.949, podem diminuir
significativamente alguns destes tipos de problemas. Zabeu et al. (2006) ainda
destaca:
Cronogramas no observados e, consequentemente, prazos de projetos
em nveis de 50% de no atendimento.
25% dos projetos de software falham ou so abandonados pela existncia
de dificuldades ou erros.
Mdulos de software no funcionam corretamente quando interagem entre si.
Programas que no fazem o que era esperado ou com uma eficcia no
adequada ao usurio.
Programas difceis de serem utilizados e entregues com defeitos (15% dos
defeitos permanecem no produto entregue ao cliente).
30% a 44% do tempo so utilizados para retrabalho nas companhias (tempo no produtivo).
Programas que param de funcionar sem motivo aparente.
captulo 1
21
Basicamente, a anlise de requisitos envolve o reconhecimento do problema, sua avaliao, uma abordagem para a soluo, sua modelagem, a especificao dos requisitos e a sua validao.
Na anlise de requisitos, importante ter definidos os conceitos de requisitos do projeto, requisitos do produto, requisitos funcionais e os no funcionais.
De acordo com Sommerville (2006), os requisitos funcionais so requisitos
diretamente ligados funcionalidade do software, descrevem as funes que o
software deve executar, como, por exemplo:
O sistema dever permitir o cadastro de produtos;
O sistema dever ter um carrinho de compras no bloco lateral;
O sistema dever permitir o pagamento por meio de carto de crdito e
boleto bancrio.
Os requisitos no funcionais, ainda de acordo com Sommerville (2006), expressam condies que o software deve atender ou qualidades especficas que
o software deve ter. Ou seja, os requisitos no funcionais colocam restries
no sistema. Podemos ainda destacar que os requisitos no funcionais so os
requisitos relacionados ao uso da aplicao em termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade, manutenibilidade e tecnologias envolvidas. Exemplos de requisitos no funcionais:
No sistema, no podero ocorrer perdas de informaes;
O sistema dever comportar com velocidade satisfatria, no superando
o tempo de 5 segundos para carregamento de pginas que hajam consultas;
O sistema dever ser compatvel com os principais navegadores.
A Anlise de Requisitos uma tarefa que envolve, em primeiro lugar, um
trabalho de descoberta, refinamento, modelagem e especificao das necessidades e desejos para o software a ser desenvolvido. Nesta tarefa, tanto o cliente
quanto o desenvolvedor iro desempenhar um papel importante, uma vez que
ser o cliente que ir efetuar a formulao (concretamente) dos pontos necessrios em termos de funcionalidades e desempenho, enquanto que o desenvolvedor atuar como investigador, consultor e ser o responsvel pela soluo
destes problemas levantados (MAZZOLA, 2010, p. 63).
22
captulo 1
De acordo com Pressman (2011, p. 151), os resultados da anlise de requisitos na especificao das caractersticas de funcionamento de software indicam a interface do software com outros elementos do sistema e estabelecem
restries que o software deve atender. Eles tambm permitem que o engenheiro de software, analista ou modelador, desenvolva as necessidades mais
bsicas estabelecidas durante as tarefas que envolvem algumas atividades da
engenharia de requisitos, como concepo, levantamento e negociao.
A etapa de anlise de requisitos caracterizada principalmente atravs da
realizao de um conjunto de tarefas, que sero discutidas nas sees seguintes.
captulo 1
23
1.4.3 Modelagem
Com o objetivo de obter um melhor entendimento dos fluxos de informao e
de controle e dos aspectos funcionais e de comportamento, o analista poder, a
partir da tarefa de avaliao e sntese, estabelecer um modelo do sistema (MAZZOLA, 2010, p. 64).
Para reforar o conhecimento sobre a viabilidade do software a ser desenvolvido, pode ser importante a criao de um prototipo de software como alternativa a analise de requisitos.
Ao criar o modelo de anlise, h algumas importantes regras prticas a serem seguidas, conforme sugere Pressman (2011, p. 152):
O modelo deve enfocar as necessidades visiveis no dominio do problema
ou do negocio. O nivel de abstracao deve ser relativamente elevado. Nao se perca nos detalhes que tentam explicar como o sistema ira funcionar.
Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos requisitos de software e fornecer uma visao do dominio de informacao, funcao e comportamento do sistema.
Postergue consideracoes de infraestrutura e outros modelos nao funcionais ate a fase de projeto. Ou seja, talvez seja preciso um banco de dados, porem
as classes necessarias para sua implementacao, as funcoes necessarias para
acessar o banco de dados e o comportamento que sera apresentado a medida
que ele for usado devem ser considerados apenas depois da analise do dominio
do problema ter sido completada.
Minimize o acoplamento do sistema. E importante representar os relacionamentos entre as classes e funcoes. Entretanto, se o nivel de interconexao
for extremamente alto, deve-se esforcar para reduzi-lo.
Certifique-se de que o modelo de requisitos agrega valor a todos os interessados. Cada participante tem um uso proprio para o modelo. Por exemplo,
os interessados no negocio devem usar o modelo para validar os requisitos;
os projetistas devem usar o modelo como base para o projeto; o pessoal da
Garantia da Qualidade (QA) deve usar o modelo para ajudar no planejamento
de testes de aceitacao.
Mantenha o modelo o mais simples possivel. Nao crie diagramas adicionais quando nao acrescentam nenhuma informacao nova. Nao utilize formas
de notacao complexas, quando uma lista simples ja bastaria.
24
captulo 1
Levantamento
e anlise de
requisitos
Especificaes
de requisitos
Relatrio de
viabilidade
Validao
de requisitos
Modelos de
sistemas
Requisitos de
usurio e do
sistema
Documentao
de requisitos
captulo 1
25
Geralmente, na documentao dos requisitos, estes so descritos com diferentes nveis de detalhes, sendo que para os usurios finais e clientes os requisitos so considerados de alto nvel, representando a ideia e a forma mental
que estes o descrevem, enquanto que para os desenvolvedores os requisitos
possuem maior detalhamento e especificaes tcnicas referentes ao sistema.
Segundo Sommerville (2006, p.47), so quatro as principais fases no processo de engenharia de requisitos, como pode ser visto a seguir:
1. ESTUDO DE VIABILIDADE
2. LEVANTAMENTO E ANLISE DE
REQUISITOS
3. ESPECIFICAO DE REQUISITOS
4. VALIDAO DE REQUISITOS
26
captulo 1
captulo 1
27
A avaliao dos artefatos produzidos na engenharia de requisitos o processo da validao. Neste processo avaliada a qualidade dos artefatos produzidos, verificando a especificao. Assim, verifica-se a clareza dos requisitos declarados, destacando possveis inconsistncias e erros. Avalia-se tambm se os
artefatos esto dentro de um padro definido para o processo e para o projeto
(MEDEIROS, 2014).
A principal forma de validao ocorre por meio da reviso tcnica.
Desenvolvedores, clientes e usurios examinam a especificao em busca de
equvocos, destacando a necessidade de maiores esclarecimentos ou informaes (MEDEIROS, 2014).
A Gesto de Requisitos realizada por uma equipe, que tem como objetivo
identificar, controlar e acompanhar as necessidades e as mudanas a qualquer
momento no projeto(MEDEIROS, 2014).
Um objetivo do projeto de software e desenvolver um quadro da arquitetura de um sistema. Um conjunto de padroes de arquitetura e reuso de software
para problemas semelhantes (PRESSMAN, 2011, p.213).
Shaw e Garlan [Sha95a] detalham as propriedades que devem ser especificadas como parte de um projeto de arquitetura (PRESSMAN, 2011, p.213):
28
captulo 1
Os principais aspectos do funcionamento de um software embasam o conceito de arquitetura de software, sendo eles a estrutura hierrquica de seus componentes e as estruturas de dados. Para Mazzola (2010, p. 88), a arquitetura de
software resulta do desenvolvimento de atividades de particionamento de um
problema, encaminhadas desde a etapa de Analise de Requisitos. Inicialmente,
h a definicao das estruturas de dados e dos componentes de software; e a solucao de parte ou de todo o problema ocorre ao longo do projeto, por meio da definicao de um ou mais elementos de software (MAZZOLA, 2010, p. 88).
No h tcnica de projeto que crie uma soluo nica. H diversas solues
para um mesmo conjunto de requisitos de software. O desafio est, justamente,
em escolher qual a melhor alternativa para a soluo do problema (MAZZOLA,
2010, p. 88).
No processo de anlise de requisitos de software h a modelagem, que possibilita um melhor entendimento das questoes de arquitetura e comportamento do problema a ser resolvido com o auxilio do software.
Um modelo realizado durante a etapa de Analise de Requisitos deve concentrar-se na representacao do que o software deve realizar e nao em como ele
o realiza.
O modelo deve enfocar aquilo que o software deve realizar, e comum e
esperado que os modelos sejam expressos graficamente, trazendo descries
complementares em texto natural ou especializada (MAZZOLA, 2010, p. 66).
captulo 1
29
A obtencao de um modelo dos requisitos do software util aos agentes envolvidos no desenvolvimento do software (MAZZOLA, 2010, p. 66):
ao analista, para uma melhor compreensao da informacao, das funcoes
e do comportamento do sistema, o que pode tornar a tarefa de analise mais
sistematica;
ao pessoal tecnico como um todo, uma vez que ele pode ser uma referencia de revisao, permitindo a verificacao de algumas propriedades, como a completude, a coerencia e a precisao da especificacao;
ao projetista, servindo de base para o projeto por meio da representacao
dos aspectos essenciais do software.
30
captulo 1
Assim, para que haja maior qualidade, fundamental que a etapa de procedimentos de teste seja realizada, sendo esta a ultima etapa de revisao da especificacao do projeto e da codificacao (MAZZOLA, 2010, p. 113).
A realizacao, de forma cuidadosa e criteriosa, dos procedimentos associados ao teste de um software assume uma importancia cada vez maior, dado o
impacto sobre o funcionamento (e o custo) que este componente tem assumido nos ultimos anos (MAZZOLA, 2010, p. 113). Assim, a etapa de teste pode
chegar a 40% do esforco total empreendido no desenvolvimento do software.
Para estas atividades de teste h uma srie de regras e objetivos trazidos por
Glen Myers (PRESSMAN, 2011, p. 121):
Teste consiste em um processo de executar um programa com o intuito
de encontrar um erro.
Um bom pacote de testes e aquele em que ha uma alta probabilidade de
encontrar um erro ainda nao descoberto.
Um teste bem-sucedido e aquele que revela um novo erro.
PRESSMAN, 2011, p. 121.
Encontrar erros o maior objetivo do teste, sendo que um teste adequadamente bem feito traz alta probabilidade de encontrar um erro. Um engenheiro
de software deve projetar e implementar um sistema tendo em mente a capacidade deste ser testado. Os testes devem ter uma serie de caracteristicas que
permitam atingir o objetivo de encontrar o maior numero de erros, como pode
ser visto abaixo (PRESSMAN, 2011, p. 429):
Testabilidade James Bach da a seguinte definicao para testabilidade:
Testabilidade de software e simplesmente a facilidade com que um programa
de computador pode ser testado. As seguintes caracteristicas levam a um software testavel.
Operabilidade Quanto melhor funcionar, mais eficientemente pode ser
testado. Se um sistema for projetado e implementado tendo em mente a qualidade, havera poucos defeitos bloqueando a execucao dos testes, permitindo
que o teste ocorra sem sobressaltos.
Observabilidade O que voce ve e o que voce testa. Entradas fornecidas
como parte do teste produzem sadas distintas. Estados e variveis do sistema
so visveis ou podem ser consultados durante a execuo. Sada incorreta facilmente identificada. Erros internos so automaticamente detectados e relatados. O cdigo-fonte acessvel.
captulo 1
31
32
captulo 1
funes so completamente operacionais, j que as funes a serem desempenhadas pelo produto so conhecidas. J nos testes de caixa branca (white box),
efetua-se os testes para averiguar se todos os componentes do produto esto
completamente ajustados e se esto realizando de maneira satisfatria a sua
funo, focando no desempenho interno do sistema ou do produto. Vamos ver
um pouco mais sobre estes testes a seguir:
captulo 1
33
Os testes de caixa branca possuem um enfoque na implementao do software, ao contrrio dos testes de caixa preta que voltam-se interface do mesmo.
Como os testes de caixa branca trabalham exaustivamente com os detalhes
internos do software, diretamente em seu cdigo fonte, os caminhos lgicos
definidos por este tambm so muito testados para avaliar o seu funcionamento e os resultados esperados.
Mazzola (2010, p. 114) aponta que apesar da importncia do teste de caixa
branca, este no garante totalmente a correo aps a realizao dos testes desta natureza, devido diversidade de caminhos lgicos que podem ser utilizados
para se chegar uma soluo, representando um grande obstculo para que se
tenha xito total.
Pode-se fazer testes utilizando estas duas abordagens, com o teste de caixa
preta e o teste de caixa branca, onde os enfoques se complementam, testando
aspectos relacionados s funcionalidades, interface e s partes internas, estruturais do sistema ou software. Estes testes so conhecidos como testes de
caixa cinza (gray box) e h diferentes opinies sobre este tipo de teste, que no e
totalmente aceito por todos e tambm chamando por alguns autores de teste
de integrao.
ATIVIDADES
01. Na sua opinio, realmente necessrio usar processos de desenvolvimento de softwares bem estruturados e de qualidade ou daria para desenvolver softwares sem passar por
estas etapas? Por qu?
02. Quais so os problemas mais comuns encontrados nas atividades de processo de desenvolvimento de software?
03. Faa uma pesquisa e relacione os principais itens que deveriam constar em um documento de especificao de software.
04. Podemos dizer que desenvolvimento de software e codificao (implementao) so a
mesma coisa? Por qu?
05. Qual a importncia dos requisitos para o desenvolvimento de um software? Quais so os
principais tipos de requisitos?
34
captulo 1
06. Assinale a alternativa que no corresponde uma das etapas do processo de desenvolvimento de software.
a)
Concepo
b)
Desenvolvimento
c)
Anlise
d)
Padronizao
e)
Teste
REFLEXO
Neste captulo, vimos que para desenvolver um Software so necessrias muitas etapas, que
devem ser realizadas por meio de mtodos e processos bem estruturados.
Assim como utilizado para a construo civil ou em projetos de produtos manufaturados, o Software tambm passa por processos e anlise que vo desde a sua concepo
at a fases de manuteno, passando basicamente tambm por planejamento, modelagem,
construo (codificao), testes e entrega final.
Por ser uma atividade complexa, natural que aconteam alguns problemas, e de fato
existem aqueles que so comuns, principalmente causados por falhas ou negligncias em
alguma das etapas do processo de desenvolvimento do Software. Voc consegue perceber
a quantidade de reas do conhecimento que so envolvidas em uma atividade de desenvolvimento? Note que usamos reas da engenharia e seus processos, gerenciamento de
projetos, gesto de pessoas, mtricas e estimativas de custo, recursos e tempo, alm do prprio conhecimento tcnico aplicado com linguagens de programao e pilhas de tecnologias
diversas, bem como abordagens de treinamento, capacitao, estratgias de suporte tcnico,
documentao e um conjunto de alinhamento do Software com a regra de negcio do qual
ele (Software) se prope a auxiliar ou a atuar.
Embora todos utilizemos vrios Softwares, sistemas e aplicaes h um tempo, no computador, que tal a partir de agora voc comear a refletir ou imaginar a complexidade que
eventualmente tenha sido para conceber o produto do qual voc utiliza atualmente? Como,
por exemplo, os seus Softwares editores de textos, editores de planilhas eletrnicas, seu navegador de Internet, seus sites, portais ou redes sociais de preferncia e assim por diante.
Imagine como foi todo o processo de desenvolvimento destes softwares, e se for necessrio,
d uma pesquisada tambm. Ser bem interessante!
captulo 1
35
LEITURA
O livro de Ian Sommerville, 9.ed., 2011, faz uma excelente abordagem sobre processos de
software e requisitos de software e sua consulta vale muito a pena.
recomendvel a leitura do artigo "Melhoria de Processos de Desenvolvimento de
software Aplicando Process Patterns", de autoria de Paulo Augusto O. Tamaki e Kechi Hirama, onde eles propem um mtodo para melhoria de processos aplicando process patterns,
com o propsito de preenhcer uma lacuna entre a estrutura metodolgica do projeto de
software e o processo de melhorias.
A leitura de captulos relacionados aos assuntos abordados da parte I do livro de Pressman, 2011, Engenharia de Software, Uma abordagem profissional, tambm outra referncia que no podemos deixar de fora e que muito contribui para o aprofundamento dos
assuntos colocados ao longo do captulo.
REFERNCIAS BIBLIOGRFICAS
COSTA, T. M., Melhoria Contnua de Processo de Software utilizando a teoria das restries.
Dissertao de Mestrado UFRJ. Rio de Janeiro, 2012. p.233.
FUGGETTA, A., 2000, Software process: a roadmap, pp. 25-34, Limerick, Irlanda.
LEITE, J. C.; O Processo de Desenvolvimento de Software. 2000. Disponvel em: <http://www.
dimap.ufrn.br/~jair/ES/c2.html>. Acesso em: 10 dez. 2014.
MARCORATTI. O processo de Software, 2014. Disponvel em: <http://www.macoratti.net/proc_sw1.
htm>. Acesso em: 28 nov. 2014.
MAZZOLA, V. B. Engenharia de Software - Conceitos Bsicos, Apostila, 2010. Disponvel em:
<https://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf>. Acesso em: 17
dez. 2014.
MEDEIROS, H. As Etapas da Engenharia de Requisitos, 2014. Disponvel em: <http://www.
devmedia.com.br/as-etapas-da-engenharia-de-requisitos/30220>. Acesso em: 02 dez. 2014.
PAULK, M., CURTIS, B., CHRISSIS, M., et al., 1993, Capability maturity model, version 1.1, IEEE
software, v. 10, n. 4, pp. 18-27.
PRESSMAN, R. S. Engenharia de Software, 7.ed. So Paulo: McGraw-Hill, 2011. p. 780.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER K. C. Qualidade de Software: Teoria e Pratica. 1. ed.
Editora Prentice Hall. Sao Paulo. 2001.
SILVA, B. C. C.; Processos e Ferramentas para o Desenvolvimento de Software Livre: Um
estudo de caso. Mestrado; UFES; 2006; p. 93.
36
captulo 1
captulo 1
37
38
captulo 1
2
Suporte e
Manuteno do
Software
OBJETIVOS
Aprender e conhecer sobre a importncia da documentao de software;
Aprender sobre manuteno de software e seus tipos;
Ter uma viso geral a respeito do suporte e treinamento na rea de softwares;
Conhecer sobre os processos de melhoria contnua.
40
captulo 2
2.1 Introduo
Em 1965, Mark Halpern introduziu o conceito de evoluo do software para
descrever as caractersticas de crescimento do mesmo. Mais tarde, o termo
evoluo, no contexto de software de aplicao, foi amplamente utilizado.
O conceito atraiu ainda mais as atenes dos investigadores aps Belady e
Lehman publicarem um conjunto de princpios que determinam a evoluo
dos sistemas de software. Os princpios eram de natureza muito geral. Em seu
artigo intitulado The Maintenance Iceberg, RG Canning comparou a manuteno de software a um iceberg para enfatizar o fato de que os desenvolvedores de software e o pessoal de manuteno enfrentam um grande nmero
de problemas. Alguns anos mais tarde, em 1976, Swanson introduziu o termo
manuteno, agrupando as atividades de manuteno em trs categorias bsicas: corretiva, adaptativa e perfectiva (TRIPATHY e NAIK, 2015, p. 1).
Manuteno o termo para qualquer esforo que colocado em uma parte
do software aps ele ter sido desenvolvido e colocado em operao. Ou, ainda, podemos definir como sendo o processo de melhoria e otimizao de um
software j desenvolvido, visando a correo de defeitos que este venha a ter
eventualmente.
A manuteno de software uma atividade importante no ciclo de vida do
software e possui certas complexidades, alm de ter um impacto significativo
no custo, de maneira elevada. Como a manuteno trata de imprevisibilidades,
h muitas atividades no estruturadas ou no esperadas, mas de fundamental
importncia que tambm haja uma srie de atividades estruturadas a fim de garantir a qualidade do software, por meio das aes de manuteno preventiva.
Atividades corretivas envolvem aes nas falhas que so descobertas, na correo destas falhas ou erros, na acomodao de novos requisitos que surgem ao
longo do tempo, mesmo aps o software estar sendo utilizado em produo,
devendo ainda buscar simplicidade, eficincia e um conjunto de atualizaes
tecnolgicas que envolvem este produto de software.
H uma quantidade razovel de documentao em softwares desenvolvidos,
envolvendo documentos de trabalhos, manuais de usurios e outros artefatos
que so gerados, em sua maioria, por engenheiros de software.
A documentao do software tambm de extrema importncia para garantir a qualidade do produto desenvolvido, em toda a sua extenso do ciclo
de vida, promovendo uma manuteno eficiente. Quanto mais completa a
captulo 2
41
documentao e com artefatos diversos gerados em todas as fases do desenvolvimento do software, maior ser a chance de garantir tambm um suporte
tcnico eficaz e de qualidade. Como o suporte tcnico lida com uma diversidade de chamados e situaes especficas no dia a dia, ter uma documentao
disponvel para prestar o servio de forma segura e pontual essencial para o
sucesso nas resolues dos chamados abertos. Alm do uso da documentao
em suporte tcnico, esta tambm contribui para os treinamentos e capacitaes que so realizados, podendo usar artefatos como, por exemplo, manuais
de uso e documentos voltados para o usurio.
Assim, podemos notar que a manuteno de software, aliada a uma boa documentao e a um suporte tcnico de qualidade e eficiente, iro contribuir
diretamente na melhoria contnua do software, melhorando cada vez mais os
processos envolvidos e mitigando problemas e erros que foram descobertos e
resolvidos ao longo da manuteno.
Vamos estudar um pouco mais sobre estes assuntos a seguir.
2.2 Documentao
A documentao de software est diretamente relacionada manuteno, suporte tcnico, treinamento e melhora contnua de um sistema. fundamental
que haja uma documentao completa e eficiente para que haja maior segurana e conforto nas prticas de manuteno, j que ela se estende por todas as fases do processo de desenvolvimento do software. Independentemente da etapa
do ciclo de vida de um sistema, a documentao pode estar presente por meio
de seus diferentes artefatos, como notaes, documentos, modelagens, workflows e qualquer outro meio que tenha a funo de documentar aquela etapa,
um processo, uma atividade, comportamento ou especificaes tcnicas.
Imagine um sistema desenvolvido sem qualquer tipo de documentao.
Neste momento, vamos tentar excluir o cdigo-fonte desta situao, onde muitos desenvolvedores fazem comentrios em meio ao cdigo e acreditam ser
isto a documentao do software. E ento, quais seriam as consequncias de
um sistema desenvolvido sem nenhum artefato gerado com o propsito de documentao? Para tentar expandir ainda mais a imaginao, vamos fazer um
paralelo com a engenharia civil, em um cenrio onde precisssemos construir
uma grande obra fsica, como uma casa, um prdio ou at mesmo construes
42
captulo 2
mais elaboradas como um robusto shopping center. Ser que daria certo a construo sem nenhuma planta (elaborada por arquitetos), sem nenhuma especificao ou sem nenhum documento que pudesse ser seguido? Ou, ainda, por
mais que contssemos com a grande experincia de alguns profissionais, que
supostamente fariam este trabalho sem nenhum documento ou planta para se
apoiarem, como seria a manuteno anos depois nesta obra, realizada por outros profissionais ou at mesmo por outra empresa? Em uma eventual reforma,
como os profissionais saberiam ao certo e com preciso os locais exatos em que
os canos, tubulaes e fiao esto sendo passados nas paredes desta construo? Ou, ainda, os materiais que foram utilizados e seus fornecedores, modelos
e especificaes? Veja que, por meio desta analogia, possvel imaginar como
tambm poderia acontecer com a engenharia de software, no desenvolvimento
de sistemas complexos. A documentao de software de extrema importncia e necessria para que todas as especificaes sejam desenvolvidas do modo
como esperado e para que todas as aes e detalhes realizados ao longo do
processo de desenvolvimento sejam devidamente anotados e estruturados em
documentos e/ou artefatos diversos.
Os requisitos so os principais elementos que norteiam o desenvolvimento
de sistemas e sua especificao clara e objetiva fundamental para definio
do software. Desta forma, a documentao surge desde esta especificao dos
requisitos, documentos de negociaes com o cliente, modelagens, anotaes,
manuais, roteiros, guias e tudo o que for gerado durante todo este grande processo de desenvolvimento. O detalhamento dos requisitos e sua clareza iro impactar diretamente na qualidade do produto final.
O propsito de um projeto outro fator determinante para avaliarmos a
obrigatoriedade dos artefatos que devero ser gerados e os seus nveis de detalhamentos. Assim, vale ressaltar que, como os requisitos sofrem constantes alteraes sob influncia dos prprios clientes, esta documentao de requisitos
no pode ser considerada algo como o contrato com o cliente, pois muitas vezes
estes clientes tambm a ignoram e impe suas prprias vontades, fazendo as
equipes cederem. O contrato um instrumento legal que acorda entre as partes
vrios pontos referentes aos servios e produto que ser desenvolvido, enquanto que uma documentao busca formalizar definies, decises referentes s
especificaes dos requisitos e outros detalhes referentes ao desenvolvimento
do software.
captulo 2
43
Fagundes (2011, p. 24) faz uma anlise com os nmeros extrados das estimativas de esforo aplicado em manuteno e traz uma abordagem interessante. Veja no quadro a seguir.
Segundo as estimativas (confiaveis ou nao) mais disseminadas no mercado, cerca de
15 a 20% do esforco de um projeto so consumidos com a atividade de requisitos.
Isso ja e um alerta, pois acredito que e tempo demais e que, provavelmente, ha muitos fatores geradores de baixa produtividade: falta de treinamento, de participacao, de
compreensao, de fontes de informacao etc. No restante do esforco gasto, 80%, numa
analise pessimista, a documentacao esta disponivel (e provavelmente em uso) para a
equipe de desenvolvimento consultar .
Imaginemos que desses 20% em requisitos, 80% sejam gastos efetivamente com
reunioes, leituras, contatos por telefone ou e-mail, elaboracao de documentacao e prototipo e revisao. A validacao com o cliente ocuparia 20% do tempo total em requisitos.
Aqui cabe tecer alguns comentarios:
A proporcao 80-20 e irreal, pois proporcionalmente gasta-se muito mais esforco
investigando do que validando, mas para efeito da brincadeira numerica, vale pensar num cenario mais pessimista;
O valor definido e em termos de esforco efetivo nao do tempo que a documentacao passa com o cliente sem sequer ser aberta para leitura e;
Muitas vezes a documentacao fica bastante tempo com o cliente e, ao final, e
aprovada sem que se faca de fato a validacao, sendo a aposicao da assinatura um
gesto pr-forma diante da proximidade do prazo.
Considerando tambem que nem todo o esforco consumido pelo restante da equipe
e feito consultando a documentacao, imaginemos que em 30% do trabalho seja feita
alguma consulta ou que o labor seja conduzido pela documentacao. E uma proporcao
razoavel, se imaginarmos que uma boa parte da equipe usa de forma intensiva a documentacao: arquitetos, gerente de projeto, analista de testes, designer, implementador...
Diante dessa brincadeira numerica, descobre-se que o cliente consumiria 4% do
esforco acompanhado da documentacao, enquanto a equipe de desenvolvimento, excluindo-se o proprio analista de requisitos, 24%, seis vezes mais. Se incluirmos o analista de requisitos, esse percentual subiria para 40%, representando 10 vezes maior uso
dentro da equipe de desenvolvimento do que para o cliente. Sem mencionar o problema
da percepcao divergente, com o cliente ignorando a documentacao em momentos que
deseja uma redefinicao de requisitos (FAGUNDES, 2011, p. 25).
44
captulo 2
A documentao descreve vrias partes do cdigo-fonte, como, por exemplo, uma funo, uma classe ou mdulo. Nela consta um conjunto de formas
de notaes que envolvem manuais gerais e de ordem tcnica, organizados
textualmente, por meio de comentrios, dicionrios, diagramas, workflows,
diagramas, modelagens diversas que podem ser representadas por grficos e
desenhos, entre outros. ainda necessrio efetuar um planejamento, identificando os documentos que sero gerados, definindo de sua organizao e relacionamento entre os outros documentos, bem como definindo a linguagem
que ser utilizada (COELHO, 2009, p. 2).
Uma documentao de software deve considerar alguns pontos importantes, como a comunicao entre a estrutura do sistema e o seu comportamento;
visualizao e controle da aquitetura do sistema; apresentar possibilidades de
simplificao e reutilizao; e gerenciar adequadamente os riscos.
Coelho (2009, p. 2) menciona os dois tipos bsicos de documentao, propostos por Michelazzo (2006), por meio de uma tabela que representa a documentao tcnica e a documentao de uso.
DOCUMENTAO TCNICA
DOCUMENTAO DE USO
Voltada ao desenvolvedor.
trador do sistema
mentarios de codigos.
captulo 2
45
Responsvel (cargo).
Participantes (opcional).
Artefatos de entrada (opcional).
Artefatos de sada.
Recursos alocados (opcional).
b) Corpo contendo o detalhamento da atividade.
A documentao de software pode unir uma srie de documentos e materiais como, por exemplo: Documento de requisitos, Documento descritivo da
arquitetura do sistema, e de cada um dos programas, listagem do cdigo-fonte
do software, documentos de validao e seus relacionamentos, alm de guias
de manuteno com os problemas j identificados, entre outros. Estes documentos tambm podem ser conhecidos como artefatos.
2.2.1 Artefatos
Conforme mencionamos acima, em uma documentao de software podem
existir vrios artefatos, que so gerados ao longo do processo. Os artefatos so
quaisquer documentos que foram gerados ou produzidos ao longo de todo o
processo de desenvolvimento de software, como diagramas, programas, documentos de textos, anotaes, contratos, especificaes de projeto, desenhos,
modelos, projetos, planos etc (WAZLAWICK, 2013, p. 21).
Em alguns modelos de processo de desenvolvimento, ou metodologias,
como, por exemplo, no Processo Unificado (UP), apenas o autor que criou o artefato pode efetuar alteraes em seu respectivo artefato, trazendo maior controle e evitando duplicaes de informaes. Em outros modelos como o XP,
por exemplo, esta prtica inversa, ou seja, os artefatos no possuem um nico
dono e todos podem contribuir com modificaes nos artefatos gerados por
outros, desde que se tenha verdadeiros motivos para isto. De qualquer modo,
muito importante que estes artefatos estejam em um ambiente dotado de
controle de verso para garantir o controle das eventuais mudanas que podem
ocorrer de maneira indevida e reverter verso correta.
46
captulo 2
captulo 2
47
48
captulo 2
captulo 2
49
A documentao gil
No livro Modelagem gil Prticas eficazes para a programao extrema, Ambler
(2004, p. 153) aborda sobre a documentao gil e traz a pergunta: Quando um documento gil? Veja abaixo:
Independentemente do que algumas pessoas lhe diro, a documentao pode, na verdade, ser muito eficaz. Quando um documento gil? Quando satisfaz aos seguintes critrios:
Documentos geis maximizam o retorno dos clientes.
Documentos geis so magros e econmicos.
Documentos geis satisfazem a um propsito.
Documentos geis descrevem informaes que tm menor probabilidade de mudar.
Documentos geis descrevem coisas boas de se saber.
Documentos geis tm um cliente especfico e facilitam o trabalho desse cliente.
Documentos geis so suficientemente precisos, consistentes e detalhados.
Documentos geis so suficientemente indexados.
Em seguida, Ambler (2004, p. 162) lista os pontos importantes relativos documentao gil:
O ponto fundamental a comunicao efetiva, no a documentao.
A documentao deve ser magra e econmica.
Diminua sua carga de trabalho o mximo que puder.
A documentao deve ser boa apenas o suficiente.
Os modelos nao sao necessariamente documentos, e os documentos nao sao necessariamente modelos.
A documentacao faz parte do sistema tanto quanto o codigo-fonte.
O objetivo principal da equipe e desenvolver software, o secundario e permitir o
proximo trabalho.
O beneficio de ter documentacao deve ser maior do que o custo de cria-la e mante-la.
Nunca confie na documentacao.
Cada sistema tem suas necessidades de documentacao proprias e unicas. Nao ha
uma solucao unica.
Pergunte se voce PRECISA da documentacao e por que acredita que PRECISA
dela, nao se a quer.
O investimento na documentacao do sistema e uma decisao de negocio, nao tecnica.
Crie documentacao apenas quando precisar dela nao a crie apenas por criar.
Atualize a documentacao apenas quando necessario.
O cliente, nao o desenvolvedor, determina se a documentacao e suficiente.
AMBLER, 2004, p. 162
50
captulo 2
CORRETIVA
o processo de desenvolvimento e testes. Este tipo de manuteno existe porque os testes de software dificilmente
conseguem detectar todos os erros.
ADAPTATIVA
PERFECTIVA OU
APERFEIOADORA
so o resultado de recomendaes de novas capacidades bem como modificaes de funes existentes solicitadas pelos usurios. Responsvel pelo maior esforo
gasto com manuteno.
PREVENTIVA
Modificaes feitas com o objetivo de melhorar o software no que se refere sua confiabilidade ou manutenibilidade.
captulo 2
51
52
captulo 2
2.3.3 Manutenibilidade
Manutenibilidade a facilidade com que um software pode ser entendido,
corrigido, adaptado, aumentado etc. Em outras palavras, quo fcil realizar a
manuteno deste software.
A manutenibilidade afetada por diversos fatores, entre eles podemos citar:
negligncia nas fases de projeto, codificao e testes;
instabilidade de pessoal;
disponibilidade de pessoal qualificado;
estrutura compreensvel do sistema;
padronizao no uso de linguagens de programao e sistemas
operacionais;
padronizao das estruturas de documentao;
disponibilidade de casos de teste;
disponibilidade de hardware adequado;
qualidade da documentao;
captulo 2
53
54
captulo 2
Design recovery: um subconjunto da engenharia reversa onde conhecimentos do domnio e informaes externas so acrescidas observao para
identificar abstraes de alto nvel que esto alm daquelas obtidas apenas
pela observao do sistema.
Redocumentao: a criao ou reviso de uma semntica representativa
equivalente com o mesmo nvel de abstrao. Produto so vises alternativas
de fcil entendimento, como diagramas de fluxo de dados, estrutura e controle;
Reestruturao: a transformao de uma representao em outra no
mesmo nvel de abstrao, preservando o comportamento externo do sistema.
Forward engineering: o desenvolvimento de software tradicional que
inicia com abstraes de alto nvel e termina com implementaes fsicas.
Reengenharia: a anlise e modificao de um sistema para reconstru-lo de
uma nova forma e sua posterior implementao.
Embora sejam termos semelhantes, existe uma diferena entre reengenharia e engenharia reversa. A reengenharia pode ser definida como um redesenho de processos no
qual ocorre uma readequao dos processos empresariais, das estruturas organizacionais, dos sistemas de informao e dos valores da organizao a fim de melhorar os
resultados dos negcios da organizao.
A engenharia reversa pode ser definida como uma forma de analisar o sistema com o
objetivo de identificar os seus componentes e o seus interrelacionamentos ou tambm
de criar outra representao do sistema ou em outros nveis mais altos de abstrao.
A figura 2.4 mostra a relao entre estes termos e o ciclo de vida do software
dividido em trs estgios, requisitos: design e implementao.
A figura 2.5 mostra uma outra representao da reengenharia, porm compatvel com a figura 2.4. Na figura 2.5, a entrada do processo um sistema legado e a sada uma verso estruturada e modular do mesmo sistema.
captulo 2
55
Requisitos
Implementao
Design
Forward engineering
Forward engineering
Engenharia reversa
Engenharia reversa
Design
recovery
Design
recovery
Reengenharia
(renovao)
Restruturao
Reengenharia
(renovao)
Restruturao
Redocumentao,
restruturao
Programa
original
Converso do
cdigo-fonte
Documentao do
programa
Engenharia
reversa
Aprimoramento da
estrutura do programa
Programa
modularizado
Dados originais
Modularizao do
programa
Reengenharia de
dados
Programa
estruturado
56
captulo 2
Avaliar
sistemas
existentes
Sistemas
existentes
Propor
mudanas
de sistemas
Modificar
os sistemas
Novo
sistema
Figura 2.6 Evoluo de sistema. Fonte: SOMMERVILLE (2006, p.53) (Adaptado pelo
autor)
captulo 2
57
58
captulo 2
AGENTES
ORGANIZAO
TECNOLOGIA DA
INFORMAO
CLIENTES E
USURIOS
contato do usurio.
o do custo de atendimento.
Uma das ferramentas de Gesto de Servios muito utilizada nas organizaes de TI a ITIL (Information Technology Infrastructure Library). A ITIL e um
conjunto de boas prticas para serem utilizadas principalmente nos servios
de TI e foi desenvolvida no final dos ano 1980 pela CCTA (Central Computer
and Telecomunications Agency), conhecida atualmente por OGC (Office for
Government Commerce), da Inglaterra, a partir de uma encomenda do governo britnico.
A ITIL possui diferentes verses, sendo que a verso de 2011 uma atualizao da Verso 3, lanada em 2007, e composta por cinco publicaes principais, a saber:
Estratgia de Servio
Desenho de Servio
Transio de Servio
Operao de Servio
Melhoria Contnua de Servio
captulo 2
59
Deste modo, o que importante ressaltarmos aqui a importncia de processos estruturados para estes tipos de servios que envolvem o suporte, dentro
do contexto da TI. Usar ferramentas de Gesto de Servios, onde possa ter padres, mtricas, indicadores e processos estruturados, auxilia as organizaes
a terem uma prestao de servios de qualidade.
A gesto destes servios de suporte dentro das organizaes pode ser feita
de diferentes formas, mas a necessidade de uma estrutura organizada, de processos definidos de relatrios de acompanhamento e painis executivos que
auxiliem os gestores, imprescindvel para que estas atividades sejam eficientes e que atendam adequadamente s necessidades dos clientes, usurios finais e de todos os envolvidos no processo da prestao deste servio de suporte
dentro da organizao.
Para que o suporte seja eficaz, tambm muito importante que a equipe
prestadora deste servio tenha acesso documentao do sistema ou software em questo. Uma documentao completa e precisa reflete diretamente na
qualidade do suporte, principalmente o suporte tcnico que envolve rotinas
de uma aplicao, funcionalidades especficas, bem como na compreenso de
processos e regras desenvolvidas que podero ser analisadas por meio de artefatos da documentao, como, por exemplo, diagramas, modelagens e outros.
O treinamento um importante momento para todos os envolvidos em um
processo de desenvolvimento de softwares. o momento em que os usurios
finais, aqueles para o qual o sistema ou software foi desenvolvido, iro aprender a utilizar o sistema e at mesmo validar alguns pontos que, teoricamente, j
deveriam ter sido passados na fase de testes.
Um treinamento pode envolver pessoas com perfis funcionais diferentes no
sistema, por isso importante ter uma abordagem correta ao pblico presente para que no cause problemas de expectativas ou dificuldades durante este
momento. Uso de guias e manuais do usurio so muito teis para que sirva
de orientao e apoio aos utilizadores do sistema. Mais uma vez notamos a importncia de uma boa documentao, com seus diversos artefatos, que nesta
hora do treinamento podem servir para extrair informaes, telas, processos e
roteiros que podero compor estes manuais para o usurio.
As consequncias de um bom e eficaz treinamento podem ser timas para
uma organizao, pois seus envolvidos podero contribuir ainda mais para
melhorias constantes e validao de requisitos importantes, uma vez que o
seu envolvimento aumenta cada vez mais e este sente-se seguro, implicando
60
captulo 2
em aumento de produtividade e aproveitamento do sistema desenvolvido, podendo enxergar novas demandas futuras ou novas implementaes que muito
contribuiro para a melhoria contnua do software.
captulo 2
61
62
captulo 2
P = PLAN
(PLANEJAMENTO)
D = DO
(FAZER, EXECUO)
C = CHECK
(CHECAGEM,
VERIFICAO)
A = ACT (AO)
captulo 2
63
Vale ressaltar que este ciclo pode seguir constantemente, sem ter a necessidade de ter um fim determinado. O importante efetuar as aes corretivas
quando terminar o primeiro ciclo e efetuar o planejamento do prximo ciclo
j realizando estes ajustes, promovendo a mehoria propriamente dita a cada
ciclo. Caso uma etapa no seja respeitada ou no executada, o ciclo pode ser
comprometido de modo significativo, por isso estes processos devem ser conduzidos de forma contnua, fazendo jus ao princpio deste mtodo (PERIARD,
2011).
Existem diversos padres, referncias e modelos reconhecidos e utilizados
em empresas e organizaes que visam melhoria da qualidade dos processos de desenvolvimento de software, entre eles destacam-se o ISO/IEC 15504, o
CMMI (Capability Maturity Model Integration), o PMBoK (Project Management
Body of Knowledge) e o SWEBoK (Software Engineering Body of Knowledge)
(HIRAMA e TAMAKI, 2007, p. 1), alm das normas ISO-9000:2000, a ISO/IEC
12207 e o MR-MPS.
Veremos algumas destas normas e modelos no prximo captulo.
ATIVIDADES
01. Cite as principais caractersticas da documentao gil.
02. Durante o processo de desenvolvimento de software, o que se pode documentar? Cite
os possveis artefatos que podem ser gerados e comente.
03. Em sua opinio, possvel efetuar manuteno de um software totalmente desprovido
de materiais ou artefatos de documentao? Explique.
04. Quando o desenvolvimento de um software entregue ao cliente, pode-se considerar o
fim do seu ciclo de vida? Por qu?
05. O suporte e/ou o treinamento devem-se iniciar apenas aps a entrega final do software,
ou estes poderiam ocorrer durante o desenvolvimento do mesmo, em entregas parciais?
06. At quando o ciclo de melhoria contnua de um software deveria ser utilizado? Explique.
64
captulo 2
REFLEXO
Um software ou sistema acaba quando ele entregue e colocado em produo?
Vimos que o software ou sistema ainda demandam muitas atividades aps a sua entrega
final ao cliente ou depois que colocado em produo. Se considerarmos apenas o projeto,
que havia escopo, plano, prazo e custo definidos, talvez podemos considerar a entrega final
como o seu fim, do projeto. Mas para o software ainda no, pois o seu ciclo de vida ainda se
estende com o seu uso e com as fases de manuteno, que podem assumir um papel de evoluo deste software, alm das aes corretivas e preventivas. Desta forma, um software ou
sistema no acaba ou termina quando ele entregue e colocado em produo. Muitas vezes,
isto pode ser apenas o comeo de uma longa trajetria que este sistema pode percorrer ao
longo de sua vida til, com evolues e novas verses que cada vez so incrementadas com
mais funcionalidades ou recursos, melhorando-o cada vez mais. Tambm pudemos notar que
muitas vezes o custo envolvido no processo de manuteno do software pode ser bem superior ao seu custo de projeto, e o tempo de uso evidentemente muito maior que o perodo
no qual ele est sendo desenvolvido.
Assim, vemos a importncia da documentao do software, que garantir condies de
efetuar uma manuteno tcnica mais eficaz, alm de trazer maior segurana para o suporte
tcnico, que poder intervir e auxiliar de maneira mais precisa.
A melhoria contnua promove a garantia de evoluo do software, que como o prprio
nome sugere, sempre com melhorias. A renovao de alguns processos e suas revises provocam um estado constante de aperfeioamento, que vai garantindo a qualidade do software,
atrelado a normas e padres reconhecidos e suportados por rgos e institutos especializados.
Tente imaginar como seria um software totalmente desprovido de documentao tcnica
e sem qualquer tipo de manuteno aps seu uso. Certamente seria um caos e muito em
breve seus requisitos podero no atender ou no se adequar s regras de negcio do qual
ele est inserido, e isto certamente ser um problema que poder causar o abandono e a
diminuio no seu ciclo de vida.
Lembre-se, em relao manuteno: voc poder gastar pouco agora ou gastar muito
mais tarde!
captulo 2
65
LEITURA
Embora a manuteno e o suporte de software sejam as atividades que possuem maior custo
na vida til de sistemas, estes so os assuntos que menos possuem materiais e livros do que
qualquer outro tpico de assuntos relacionados Engenharia de Software.
De qualquer maneira, podemos mencionar importantes obras recentes da literatura, em
ingls, de acordo com Pressman, 2011:
Effective Software Maintenance and Evolution (de Auerbach Jarzabeck, 2007).
Software Maintenance: Concepts and Practice, World Scientific Publishing Co., 2d. ed.,
2003, de Grubb e Takang.
Practical Software Maintenance (Wiley, 1996).
REFERNCIAS BIBLIOGRFICAS
ABREU, V. F. De.; FERNANDES, A. A.; Implantando a Governanca de TI: uma estrategia a gestao
de processos e servicos. 2. ed. Rio de Janeiro: Brasport, 2008. Acesso em: 15 jan. 2015.
AMBLER, S. W.; Modelagem gil - Prticas eficazes para a Programao Extrema e o Processo
Unificado. Bookman. 2004. p. 351.
COELHO, H. S.; Documentao de Software: uma necessidade. Texto Livre; n 2; vol. 1; UFMG;
2009.
COSTA, T. M., Melhoria Contnua de Processo de Software utilizando a teoria das restries.
Dissertao de Mestrado UFRJ. Rio de Janeiro, 2012. p. 233.
FAGUNDES, R. M., Engenharia de Requisitos - Do perfil do analista de requisitos ao
desenvolvimento de requisitos com UML e RUP. Salvador, 2011. p. 216.
HIRAMA, T.; TAMAKI, P. A. O.; 2007. Melhoria de Processos de Desenvolvimento de Software
Aplicando Process Patterns. Disponvel em: <http://www.dcc.ufla.br/infocomp/artigos/v6.1/art09.
pdf> Acesso em: 04 dez. 2014.
HUMPHREY, W.S., 1989, Managing the Software Process, Boston, Addison-Wesley Professional.
MAGALHES, I. L. R. G.; Indicadores de Desempenho para Service Desk - baseado na
Strategic Activity System. Apresentao. 2008. Disponvel em: <http://pt.slideshare.net/ivan_luizio/
indicadores-de-desempenho-para-service-desk-com-base-na-sas-presentation>. Acesso em: 14 fev.
2015.
MAGALHAES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de servicos de TI na pratica:
uma abordagem com base na ITIL. Sao Paulo: Novatec Editora, 2007. Serie gerenciamento de TI.
MAZZOLA, V. B. Engenharia de Software - Conceitos Bsicos, Apostila, 2010.
66
captulo 2
captulo 2
67
68
captulo 2
3
Introduo aos
Padres de PDS
OBJETIVOS
Aprender sobre alguns dos principais padres de PDS (Processos de Desenvolvimento de
Software);
Conhecer o modelo da capacidade de maturidade (CMM);
Aprender sobre a norma ISO 15504, conhecida por SPICE;
Conhecer a norma ISO 12207, que trata dos processos do ciclo de vida do software;
Conhecer o modelo de qualidade de processo MPS/BR.
70
captulo 3
3.1 Introduo
Sabemos que existem processos bem definidos para desenvolver um produto
de software, mas ser que todas as organizaes os seguem de uma mesma maneira ou ser que cada uma adota seus processos a seu critrio. Sim, possvel
as empresas adotarem seus prprios processos ou adaptar alguns j conhecidos. Mas imagine se existissem alguns padres j bem estruturados, por meio
de normas que visassem a qualidade ou at mesmo alguns modelos de maturidade, do ponto de vista de processos. Ao adotar padres de desenvolvimento e
ao definir os processos em uma empresa, esta est ganhando em maturidade e
contribuindo para a qualidade do produto final, devido prtica de processos
bem estabelecidos.
Desta forma, existem diversos padres de desenvolvimento de software,
onde cada um possui um enfoque especfico que busca normatizar ou trazer
modelos a serem seguidos pelas organizaes para estabelecer as melhoras
prticas em relao aos seus processos e a fatores crticos de sucesso.
A maturidade de uma empresa avaliada pela definio e estabelecimento dos processos nela praticados. Alguns modelos classificam uma empresa
em diferentes nveis de maturidade, trazendo reas-chaves para cada nvel,
auxiliando a organizao a focar seus esforos em reas determinantes para o
seu momento e conseguir se estruturar de acordo com seus processos. Quanto
mais bem definido e estabelecido for os processos em uma empresa, maior
ser a sua maturidade. Por isso importante no confundir maturidade com
tempo cronolgico. Uma empresa relativamente nova, em termos de idade
de vida, pode ser muito mais madura do que uma outra empresa que tenha
dcadas de vida, pois a primeira pode ter seus processos definidos e bem estruturados, diferentemente da segunda que, eventualmente, pode no ter
processos to bem estruturados, mesmo com um tempo maior de existncia.
Evidentemente que a maturidade tambm no est associada idade das pessoas que ali trabalham e sim ao grau de maturidade de seus processos dentro
da organizao.
Vamos ver alguns modelos de maturidade e padres que trabalham essencialmente com processos.
captulo 3
71
72
captulo 3
ORGANIZAES IMATURAS
Processo improvisado.
No existe base histrica.
No h maneira objetiva de julgar a qualidade do
produto.
Qualidade e funcionalidade do produto sacrificadas.
No h rigor no processo a ser seguido.
Resoluo de crises imediatas.
3.2.1.2 Nveis
Existem 5 nveis de maturidade usados no CMM. Cada um dos nveis possui
caractersticas prprias.
Segundo o CMM (1997), o nvel 1 compreende a maioria das organizaes,
chamado de Inicial e engloba as organizaes mais imaturas. Neste nvel no h
nenhuma metodologia implementada e tudo ocorre de forma desorganizada.
No nvel 5, chamado de otimizado, onde esto as organizaes mais maduras, cada detalhe do processo de desenvolvimento est definido, quantificado
e acompanhado e a organizao consegue at absorver mudanas no processo
sem prejudicar o desenvolvimento.
captulo 3
73
NVEL CMM
DESCRIO
O processo de desenvolvimento desorganizado e at cati-
1 INICIAL
2 REPETVEL
3 DEFINIDO
tadas, padronizadas e integradas em um padro de desenvolvimento da organizao. Todos os projetos utilizam uma verso
aprovada e adaptada do processo padro de desenvolvimento
de software da organizao.
So coletadas medidas detalhadas da qualidade do produto
4 GERENCIADO
5 OTIMIZADO
de um feed-back quantitativo dos processos e pelo uso pioneiro de ideais e tecnologias inovadoras.
74
captulo 3
Capacitao dos
processos
da organizao
reas-chaves
alcaam
organizadas por
Metas
Caractersticas
comuns
dirigem
contm
Implementao ou
institucinalizao
Prticas-chaves
descrevem
Infraestrutura ou
atividade
captulo 3
75
Para isto, cada rea-chave possui vrios grupos de atividades de institucionalizao. Essas atividades, quando executadas, foram a empresa a continuar
fazendo o que foi feito anteriormente para conseguir a melhoria, dificultando,
assim, o retrocesso nas atividades de implementao. As atividades de institucionalizao so divididas nos seguintes grupos, chamados de Caractersticas
Comuns (Common Features):
Comprometimento em executar (Commitment to Perform): descrevem as
aes que a organizao deve ter para garantir que o processo foi implantado
e qual ele persiste. Estas aes envolvem ter uma poltica organizacional documentada e boa liderana.
Capacitao para executar (Ability to Perform): descreve as pr-condies
que devem existir no projeto ou na organizao para implementar o processo
de software com competncia. Envolvem recursos, estrutura organizacional e
treinamento.
Atividades realizadas (Activities Performed): descreve as atividades, papis e procedimentos necessrios para implementar uma KPA. Envolvem a implantao de planejamento e procedimentos, realizao do trabalho, acompanhamento e tomar aes corretivas, se necessrio.
Medio e anlise (Measurement and Analysis): medies bsicas necessrias para avaliar o status da rea-chave. Estas medidas so usadas para controlar e melhorar o processo.
Verificao da implementao (Verifying Implementatton): aes que
garantem a conformidade das demais atividades com os processos estabelecidos. Envolvem as aes de verificao por parte da gerncia superior da organizao, dos gerentes dos projetos e de um grupo independente de garantia da
qualidade.
Apresenta-se como exemplo, a seguir, a estrutura da rea-chave de gesto de
requisitos. Esta rea a primeira do nvel do CMM, e uma das mais simples em
quantidade de prticas-chaves.
A documentao do CMM apresenta maiores detalhes a respeito de cada
prtica. A descrio apresentada na tabela 3.3 Exemplo da KPA de Gesto de
Requisitos simplificada em relao definio oficial das prticas do CMM.
76
captulo 3
METAS
sitos documentados.
Consistncia permanente de planos, produtos e atividades com os
requisitos.
Comprometimento
em executar
de requisitos.
Designao de responsveis pelos requisitos, em todos os projetos.
Documentao dos requisitos alocados ao
Capacitao para
software.
executar
PRTICASCHAVE
Atividades a executar
Medio e anlise
Verificao da imple-
mentao
dos projetos.
Reviso e auditoria das atividades de Gesto de requisitos pelo Grupo de garantia da
qualidade de software.
captulo 3
77
os requisitos devem sofrer reviso prvia dos grupos afetados, dos quais o
grupo dos desenvolvedores o mais bvio;
estes requisitos devem ser usados como base para o planejamento e para
as diversas atividades do projeto;
se os requisitos forem alterados ao longo de um projeto, estas alteraes devem ser aprovadas pelos grupos afetados e incorporadas de forma
disciplinada.
Para garantir que estas atividades sejam executadas de forma permanente
e estvel, o CMM requer que a organizao tenha uma poltica documentada
para a rea; no basta existir um costume no escrito.
Todo projeto tem de ter um responsvel pelos requisitos, oficialmente designado. Todos os requisitos alocados ao software (dentre os requisitos do sistema) tm de ser documentados. As atividades de gesto de requisitos devem
receber recursos suficientes e o pessoal envolvido deve ser treinado no assunto.
Devem ser feitas medies de status da gesto de requisitos, por exemplo,
o grau de estabilidade dos requisitos de cada projeto. E, finalmente, a Gesto
de requisitos deve ser acompanhada, em nvel mais alto, pela alta direo da
organizao, chamada no CMM de Gerncia Executiva (snior management) em
nvel detalhado, pelos gerentes dos respectivos projetos e por um grupo independente de Garantia da qualidade, que fornea gerncia executiva informaes independentes dos gerentes de projeto.
Com pequenas variaes, as atividades de institucionalizao das outras
reas-chaves do CMM funcionam de forma semelhante. Por outro lado, as atividades de implementao so bastante especficas de cada rea-chave.
3.2.1.4 Nvel 1 Inicial
A organizao nvel 1 representa o estgio inicial dos produtores de software.
Ela utiliza processos informais e mtodos ad hoc, s vezes descritos como caticos. Muitas destas organizaes so bem sucedidas, j que o mercado de software ainda tolerante em relao m qualidade dos produtos. Muitas vezes,
a qualidade do marketing pode ocultar deficincias tcnicas, ou existe pouca
competio em muitos setores deste mercado. A cultura no nvel inicial muito
baseada no valor dos indivduos. comum a dependncia em relao a heris
tcnicos e gerenciais.
78
captulo 3
captulo 3
79
80
captulo 3
81
82
captulo 3
DEFECT PREVENTION
PREVENO DE DEFEITOS
consiste em desenvolver atividade para a preveno dos defeitos por meio da identificao e remoo das suas causas
As prticas dos nveis inferiores do CMM servem como base para os nveis
superiores. Implementar os nveis fora da ordem leva a riscos, os quais fazem
com que as prticas sejam abandonadas ou relaxadas exatamente no instante
em que elas so mais necessrias e principalmente nos momentos de crise.
A definio de processos tcnicos que so previstos nas prticas do nvel 3
tem poucas chances de institucionalizao se as bases gerenciais do nvel 2 no
estiverem estabelecidas e institucionalizadas.
Podemos perceber que, conforme vamos chegando ao nvel 5, o nmero de
reas-chave vai diminuindo. Ento, razovel concluir que as organizaes que
captulo 3
83
amadureceram, principalmente nos nveis 2 e 3, tendem a realizar mais facilmente as atividades para conseguirem os nveis 4 e 5 do CMM, pois a cultura de
melhoria j foi implantada e j est institucionalizada.
CONEXO
Recentemente apareceu o CMMI (Capability Maturity Model Integration Integrao do
Modelo de Maturidade e Capacidade). Trata-se de uma evoluo do CMM e tem como objetivo integrar diferentes modelos e disciplinas na rea de qualidade de software. Possui 3
modelos: CMMI-DEV (para desenvolvedores), CMMI-ACQ (para os processos de aquisio
e terceirizao de bens e servios), CMMI-SVC (para empresas prestadoras de servios).
Saiba mais sobre o CMMI, os links a seguir so bastante interessantes:
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-cmmi-no-brasil: Lista das
empresas no Brasil que passaram pela certificao CMMI
http://www.cmmi.de/#el=CMMI/0/HEAD/folder/folder.CMMI: Em ingls. Trata-se de
um navegador para os tpicos dos modelos do CMMI.
http://www.blogcmmi.com.br/. um blog com vrios outros links e assuntos relacionados com CMMI.
84
captulo 3
(Software Process Improvement and Capability Determination) com base nos modelos j existentes como ISO 9000 e CMM.
Segundo a norma, uma avaliao de processo de software uma investigao e anlise disciplinada de processos selecionados de uma unidade organizacional em relao a um modelo de avaliao de processo. A ISO/IEC 15504
define um modelo de referncia de processo que identifica e descreve um conjunto de processos considerados universais e fundamentais para a boa prtica da engenharia de software, e define seis nveis de capacidade, sequenciais
e cumulativos, que podem ser utilizados como uma mtrica para avaliar como
uma organizao est realizando um determinado processo e tambm podem
ser utilizados como um guia para a melhoria. Veja na tabela 3.4 os seis nveis:
NVEL
INCOMPLETO 0
DESCRIO
Processo no existe ou falha em atingir seus objetivos.
EXECUTANDO 1
GERENCIADO 2
ESTABELECIDO 3
PREVISVEL 4
OTIMIZADO 5
captulo 3
85
No Brasil, um modelo de software que tem sido bastante adotado o MPS.BR (Melhoria de Processo de Software Brasileiro). Este modelo foi desenvolvido no Brasil para
poder adaptar os modelos conhecidos internacionalmente para a realidade brasileira,
onde a maioria das empresas de software so constitudas por pequenas e mdias empresas. A Softex constatou em pesquisas que estas empresas, na sua maioria, apenas
adotam boas prticas da engenharia de software quando estas so exigidas em avaliaes de processos. O objetivo da Softex fazer com que as empresas adotem sempre
as boas prticas por meio do MPS.BR.
CONEXO
Conhea um pouco mais sobre o MPS.BR:
http://www.softex.br/portal/softexweb/uploadDocuments/sbes2011_melhoria_processo.pdf. Excelente artigo que mostra um panorama sobre o processo de melhoria de software no Brasil.
http://www.softex.br/portal/softexweb/uploadDocuments/COMPUTACAO_Brasil_Edicao_OUT-DEZ-2010.pdf. Outro bom artigo sobre o processo de melhoria de software no Brasil
usando o MPS.BR.
http://www.softex.br/portal/softexweb/uploadDocuments/CIBSE2010_MPSBR_CameraReady.pdf. Artigo que mostra a verso atual do MPS.BR e resultados de um estudo de caso.
86
captulo 3
1. Processos fundamentais: incio e execuo do desenvolvimento, operao ou manuteno do software durante o seu ciclo de vida.
a) Aquisio: atividades de quem um software. Inclui: definio da necessidade de adquirir um software (produto ou servio), pedido de proposta, seleo de fornecedor, gerncia da aquisio e aceitao do software.
b) Fornecimento: atividades do fornecedor de software. Inclui preparar
uma proposta, assinatura de contrato, determinao dos recursos necessrios,
planos de projeto e entrega do software.
c) Desenvolvimento: atividades do desenvolvedor de software. Inclui: anlise de requisitos, projeto, codificao, integrao, testes, instalao e aceitao do software.
d) Operao: atividades do operador do software. Inclui: operao do software e suporte operacional aos usurios.
e) Manuteno: atividades de quem faz a manuteno do software.
2. Processos de apoio: Auxiliam outro processo.
a) Documentao: Registro de informaes produzidas por um processo
ou atividade. Inclui planejamento, projeto, desenvolvimento, produo, edio, distribuio e manuteno dos documentos necessrios a gerentes, engenheiros e usurios do software.
b) Gerncia de configurao: identificao e controle dos itens do software. Inclui: controle de armazenamento, liberaes, manipulao, distribuio e
modificao de cada um dos itens que compem o software.
c) Garantia da qualidade: garante que os processos e produtos de software
estejam em conformidade com os requisitos e os planos estabelecidos.
d) Verificao: determina se os produtos de software de uma atividade
atendem completamente aos requisitos ou condies impostas a eles.
e) Validao: determina se os requisitos e o produto final (sistema ou software) atendem ao uso especfico proposto.
f) Reviso conjunta: define as atividades para avaliar a situao e produtos de uma atividade de um projeto, se apropriado.
g) Auditoria: determina adequao aos requisitos, planos e contrato,
quando apropriado.
h) Resoluo de problemas: anlise e resoluo dos problemas de qualquer
natureza ou fonte, descobertos durante a execuo do desenvolvimento, operao,
manuteno ou outros processos.
captulo 3
87
3.5 MPS.BR
A SOFTEX (Associao para Promoo da Excelncia do Software Brasileiro),
com o apoio do Ministrio da Cincia e Tecnologia (MCT), da FINEP (Financiadora de Estudos e Projetos) e do BID (Banco Interamericano de Desenvolvimento), coordena um programa para a Melhoria de Processo do Software Brasileiro, desde 2003, chamado de MPS.BR (Guia Geral MPS.BR, 2006, p. 4), sendo
um modelo de qualidade de processos das empresas de desenvolvimento de
88
captulo 3
captulo 3
89
Modelo de refrncia
(MR-MPS)
Guia geral
Guia de
aquisio
Projeto MPS.BR
Mtodo de avaliao
(MA-MPS)
Modelo de negcios
(MN-MPS)
Guia de
avaliao
Documento
do projeto
90
captulo 3
A (Em otimizao);
B (Gerenciado quantitativamente);
C (Definido);
D (Largamente definido);
E (Parcialmente definido);
F (Gerenciado);
G (Gerenciado parcialmente).
5
4
Em otimizao
Gerenciado quantitativamente
C
3
Definido
Largamente definido
E
2
Parcialmente definido
Gerenciado
Parcialmente gerenciado
91
captulo 3
NVEL A
NVEL B
NVEL C
NVEL D
NVEL E
NVEL F
NVEL G
Cada nvel possui um perfil de processos e capacitao de processos definidos, conforme demonstra De Bona e Santos (2012) na tabela a seguir:
H uma gerncia de projetos e uma gerncia de requisitos, o que demonstra um nvel de maturidade bastante baixo. Porm, como se sabe, na gerncia de projetos existem algumas tarefas
essenciais, que precisam ser realizadas em qualquer projeto de software, como identificao e
monitoramento de atividades referentes ao projeto. No que diz respeito gerncia de requisitos,
quer dizer que a empresa tem uma boa habilidade de lidar com as mudanas que os requisitos
sofrem ao longo do desenvolvimento de um projeto.
H uma maturidade um pouco maior por parte da empresa, existindo uma garantia da qualidade
do produto, bem como controle nas aquisies (de produtos e servios), gerncia de configurao e medio. A primeira diz respeito a garantir que os produtos e processos estejam de acordo
com o plano e recursos predefinidos. Isso no garante que o software ser um sucesso, porm
o primeiro passo para tal. J o controle nas aquisies diz respeito definio de necessidades
de aquisio, bem como definio de fornecedores e outros pontos importantes para a compra
de produtos e/ou servios. A gerncia de configurao responsvel por estabelecer e controlar
os resultantes de um processo, enquanto a medio diz respeito coleta e anlise dos dados
relativos aos produtos desenvolvidos, bem como aos processos implementados.
Garante uma organizao ainda maior nos processos. Ele trs a adaptao do processo para
gerncia de projeto, a definio do processo organizacional, bem como sua avaliao e melhoria, trazendo tambm o processo de treinamento dentro da empresa de forma global. O primeiro
processo diz respeito a estabelecer e gerenciar o projeto, com envolvimento dos clientes e de
acordo com princpios predefinidos. J o segundo e terceiro dizem respeito organizao da
empresa no que diz respeito a fazer software. Eles so responsveis por definir esses processos, bem como avali-los e melhor-los.
o nvel de maturidade intermedirio, trazendo algumas ideias de desenvolvimento de requisitos, bem como utilizao de tcnicas para garantir a qualidade do software, como validao e
verificao. Nesse nvel de maturidade, a empresa capaz de coletar os requisitos juntamente
com o cliente, deixando tudo largamente definido a priori. Posteriormente, h a necessidade de
confirmar se esses requisitos foram atingidos, o que trs a soluo tcnica (onde h a especificao tcnica dos requisitos validados), a validao, verificao, a integrao e instalao do
produto, bem como sua liberao.
Traz alguns processos mais avanados, como gerncia de riscos e anlise de deciso e resoluo. O primeiro diz respeito a diminuir os riscos que mudanas de pessoal possam trazer para
os projetos, evitando atrasos no cronograma. Esse um ponto muito importante, a que todas
as empresas devem estar atentas, uma vez que o cliente quer que o cronograma seja cumprido.
J a anlise de deciso e resoluo responsvel por analisar as decises que foram tomadas
utilizando um processo formal de avaliao.
Traz uma gerncia quantitativa do projeto, alm de calcular o desempenho do processo organizacional. O propsito da gerncia quantitativa bem interessante, e diz respeito a monitorar e
determinar os projetos em relao aos seus objetivos de qualidade e desempenho, garantindo
que o software tenha qualidade. O desempenho do processo organizacional calculado para
que se tenha um entendimento da qualidade dos processos que a organizao est realizando.
H uma maturidade plena da empresa. Ele trs processos de anlise de causas e resoluo e
inovao na organizao. O objetivo do primeiro identificar e, obviamente, evitar no futuro causas de defeitos, seja nos processos ou nos projetos realizados. J a inovao parte essencial
em qualquer empresa consolidada no mercado, trazendo a ideia de sempre buscar melhorias e
evoluo para melhor.
92
captulo 3
captulo 3
93
processos de apoio
garantia de qualidade;
gerncia de configurao;
validao;
medio;
verificao;
treinamento.
No MA-MPS (Mtodo de avaliao para melhoria do processo de software), a
avaliao est assim estruturada, de acordo com Wikipdia (2015):
Avaliao MA-MPS
Equipe de avaliao: 3 a 8 pessoas, sendo:
1 avaliador lder
no mnimo 1 avaliador adjunto
no mnimo 1 tcnico da empresa
Durao: 2 a 4 dias;
Validade: 3 anos;
Estruturao da Avaliao:
Planejar e preparar avaliao
Plano de Avaliao / Descrio dos indicadores de processo;
Conduzir Avaliao
Resultado da avaliao;
Relatar resultados
Relatrio da avaliao;
Registrar e publicar resultados
Banco de dados Softex
O MPS.BR tem sido um verdadeiro sucesso e ainda fornece diversos meios
para que se difunda de maneira estruturada, por meio de provas oficiais, cursos
e capacitando profissionais. De acordo com o site oficial do projeto (www.softex.br/mpsbr), h quase 6 mil profissionais capacitados no mercado, e a tendncia de que esse nmero cresa muito nos prximos anos, conforme afirmam
De Bona e Santos (2012). Portanto, vemos que o MPS.BR um modelo que vem
adotando as melhores prticas de Engenharia de Software, sendo uma grande
94
captulo 3
ATIVIDADES
01. Quais seriam os impactos de se adotar uma norma em uma empresa de desenvolvimento de software?
02. Quais so os nveis do CMM/CMMI? Explique cada um de seus nveis.
03. Por que to difcil conseguir e estabelecer o nvel 5 do CMM em uma empresa?
Explique.
04. Cite as 3 guias (documentos) do MPS.BR e explique cada uma delas.
05. Pesquise sobre as reas-chave (KPA) do CMM e apresente-as de acordo com cada nvel.
REFLEXO
Neste captulo vimos que existem vrios modelos que podem ser usados e isto pode ser um
difcil trabalho para os profissionais de TI escolher entre esses modelos e padres e selecionar o melhor a ser aplicado na situao necessria.
Porm, no uma escolha exclusivamente do setor de TI, uma deciso conjunta com
outros setores da empresa e que deve envolver a alta direo, em um trabalho corporativo
conjunto. Logo, mais uma vez fica clara a importncia fundamental da TI nas empresas.
Mas, a realidade brasileira ainda diferente dos exemplos que encontramos nas bibliografias e estudos de caso. A grande maioria das empresas de software nacional ainda de
pequeno ou mdio porte e no possuem uma estrutura to grande para implantar modelos
de qualidade de software como os mostrados aqui. Neste caso, modelos como o MPS/BR
so usados e largamente difundidos entre os grupos de software nacional e contribuem
como mais uma varivel para o gestor de TI ter que escolher entre os modelos existentes.
Desta forma, podemos ver que os modelos de processos para a qualidade de software
so excelentes, porm necessitam de um detalhe corporativo e institucional para ser utilizado
na sua plenitude: ter a participao de toda a empresa e um bom patrocinador interno, de
preferncia, proveniente da diretoria da empresa.
captulo 3
95
LEITURA
Sobre o MPS.BR existem alguns artigos interessantes disponveis na Internet, bem como o
Guia Geral que contm a descrio geral do MPS.BR e detalha o Modelo de Referncia (MR
-MPS) e as definies comuns necessrias para seu entendimento e aplicao, que pode ser
encontrado aqui: http://migre.me/oJyRV
Uma abordagem para conduo de iniciativas de melhoria de processos de software, disponvel em: http://migre.me/oJyDC
Gerenciamento da Qualidade no Desenvolvimento de Sistemas: Plano de Transio do
nvel 2 do SW-CMM para o nvel 2 do CMMI-DEV em uma Empresa de Tecnologia: http://
migre.me/oJyOw
Documento da ISO/IEC15504, disponvel em: http://migre.me/oJz5S
O MC2Q-SQ - Um Mtodo para a Melhoria Contnua da Qualidade de Software apoiado
em CMMe SPICE - e sua Aplicao Experimental como base nos Programas de Melhoria da
Qualidade de Software, disponvel em: http://migre.me/oJzdM
REFERNCIAS BIBLIOGRFICAS
COSTA, T. M., Melhoria Contnua de Processo de Software utilizando a teoria das restries.
Dissertao de Mestrado UFRJ. Rio de Janeiro, 2012. p. 233.
De BONA, G.; SANTOS, I. R. Gerenciando requisitos com MPS.BR. Revista Engenharia de Software,
Ed. 63, 2012. Disponvel em: <http://www.devmedia.com.br/gerenciando-requisitos-com-mpsbr/29375>. Acesso em: 15 dez. 2014.
Guia Geral MPS.BR, 2006. Associao para Promoo da Excelncia do Software Brasileiro
SOFTEX. MPS.BR - Melhoria de Processo de Software Brasileiro - Guia Geral. 2. ed. 2006.
SILVA, B. C. C. Integrando Agilidade com maturidade. Revista Engenharia de Software Magazine.
Ed. 59. Disponvel em: <http://www.devmedia.com.br/integrando-agilidade-com-maturidade-revistaengenharia-de-software-magazine-59/28197>. Acesso em: 16 dez. 2014.
WIKIPDIA. Melhoria de Processos do Software Brasileiro. Disponvel em: <http://pt.wikipedia.
org/wiki/Melhoria_de_Processos_do_Software_Brasileiro>. Acesso em: 02 fev. 2015.
96
captulo 3
4
Modelos de Ciclo de
Vida de Software
Neste captulo veremos sobre alguns dos principais modelos de ciclo de vida
de software e suas principais caractersticas. Ciclos de vida de software representam as etapas ou fases que um software passa desde a sua concepo
at a sua retirada. de extrema importncia compreendermos estas fases e
seus processos relacionados, bem como perceber a existncia de diferentes
abordagens.
Como o desenvolvimento de softwares uma tarefa complexa e a cada dia
os clientes e o prprio negcio exigem maior qualidade no produto final entregue e com o menor tempo possvel, vrias metodologias tentam impulsionar
ou organizar estas atividades e processos dentro da Engenharia de Software.
Mtodos clssicos da engenharia, com um processo linear, recheado de planejamento, especificao de requisitos bem definidos e uma pesada documentao tm sido sufocados pela presso do tempo de entrega e pela concretizao
daquilo que estava no papel. Em virtude da evoluo destes processos e diferentes metodologias, existem mtodos com uma abordagem gil. Processos
geis ilustram outras caractersticas diferentes dos mtodos tradicionais e tambm possuem grandes desafios para serem devidamente implementados nas
organizaes.
Os processos de software so melhorados sempre para aumentar a qualidade do produto final com reduo de custo e tempo. Assim, este captulo abordar os modelos de ciclo de vida de software, ou seja, os seus modelos de processos, envolvendo o modelo cascata, o processo iterativo e o processo gil, entre
os vrios modelos existentes.
OBJETIVOS
Aprender sobre modelos de ciclo de vida de software;
Conhecer o processo Cascata e suas principais utilidades;
Ter uma viso geral sobre processos Iterativos;
Conhecer a metodologia gil e seus processos.
98
captulo 4
4.1 Introduo
Todas as vezes que a palavra software vista ou ouvida, associamos este termo a
um programa de computador. Porm, o software no apenas o programa, mas
sim uma srie de documentos, modelos de dados, configurao, requisitos etc.,
que o compe. Esses elementos so chamados de artefatos de software.
Os engenheiros de software, que so os responsveis pela manuteno destes artefatos, usam vrias tcnicas para ger-los, e estas provm de outras semelhantes s empregadas na engenharia tradicional.
Existem, na verdade, dois tipos principais de produtos de software segundo
Sommerville (2007):
Produtos genricos: esses produtos so aqueles encontrados disponveis
para venda em vrios tipos de mdias. So tambm chamados de software de
prateleira. Como exemplo podemos citar os pacotes para escritrio, editorao grfica, sistemas operacionais comerciais etc.
Produtos sob encomenda: esses produtos so aqueles desenvolvidos para
uma determinada finalidade encomendada pelo cliente. Como exemplo, podemos citar os softwares para dispositivos embarcados, para um determinado processo de negcio.
Porm, nos principais sistemas ERP e outros, so possveis ter um tipo de
produto hbrido, ou seja, um produto que foi desenvolvido por uma empresa
para ser soluo para vrias reas de negcio de uma empresa, mas tambm
pode sofrer adaptaes para suprir uma determinada especificidade em uma
situao ou processo de negcio.
Este tipo de situao chamado de customizao de mdulos.
A engenharia de software , portanto, uma rea da engenharia aplicada
produo de software.
Porm, a engenharia de software pode ser confundida com uma disciplina
chamada engenharia de sistemas. H uma pequena diferena entre as duas: a
engenharia de sistemas trata exclusivamente da rea de desenvolvimento de
sistemas e seus aspectos, incluindo hardware, software e engenharia de processo. A engenharia de software uma parte desse processo.
Entre os principais conceitos a serem aprendidos em engenharia de
software, o processo de software um dos principais.
captulo 4
99
Existem vrios processos de software diferentes, como j citado, porm algumas atividades so fundamentais e comuns a todos eles. Estas atividades so:
Especificao de software: essa atividade envolve a definio de funcionalidades e as restries existentes na sua operao.
Projeto e implementao: essa atividade abrange as questes relativas
produo de um software que atenda especificao inicial.
Validao de software: so as atividades que garantem que o software
tenha validade junto ao cliente
100
captulo 4
CONEXO
A seguir alguns links referentes s ferramentas case existentes no mercado. Alm dessas,
obviamente existem outras, porm os links abaixo so o incio de outras pesquisas que voc
pode fazer.
http://www.devmedia.com.br/post-2174-Ferramentas-case-parte-iv.html: Artigo exemplificando o Microsoft Visio como ferramenta CASE.
http://www.casestudio.com/enu/default.aspx. Site do software Case Studio. Trata-se de
um software bastante popular para o apoio s atividades de desenvolvimento. Em ingls.
http://erwin.com/. O ErWin outro exemplo de ferramenta CASE bastante usada no mercado. Em ingls.
Padronizando processos, a comunicao melhorada, o tempo de treinamento reduzido e o apoio a um processo automatizado fica mais econmico. A padronizao contribui tambm para a introduo de novos mtodos e
tcnicas de engenharia de software e, consequentemente, do uso de melhores
prticas na arte da engenharia de software.
Durante esta disciplina, vamos ver estes tpicos com um pouco mais de
detalhes.
Vamos comear conceituando o ciclo de vida do software.
captulo 4
101
102
captulo 4
suficientes para tal. Logo, de se esperar que ocorra uma crise entre os componentes deste ambiente. Esta crise foi chamada de Crise do Software e foi
nomeada assim pela primeira vez por Edsger Dijkstra em um artigo de 1972.
(DIJKSTRA, 1972).
Existem vrias causas para a crise do software e cada autor a trata de uma
maneira diferente, porm basicamente, temos as seguintes principais causas
relacionadas com a crise do software:
os problemas a serem resolvidos estavam se tornando cada vez mais
complexos;
no existiam tcnicas adequadas para o desenvolvimento e soluo dos
problemas;
no existiam tcnicas que pudessem validar o software que foi desenvolvido;
o processo de desenvolvimento do software tambm estava se tornando
complexo.
A crise do software pode ser percebida de diversas formas, principalmente
em situaes nas quais as falhas do software aparecem, por exemplo quando:
o oramento no suficiente e acaba estourando;
o prazo curto demais e acaba estourando;
o software no atende aos requisitos, demonstrando ter baixa qualidade
(vamos ver isso com mais detalhes frente);
o processo de desenvolvimento de software difcil de ser gerenciado;
a manuteno do software fica difcil de ser efetuada, principalmente nas
questes relacionadas com a codificao;
h problemas na documentao do software: ruim, falha, pouca,
imprecisa, inadequada etc.
O interessante que vrios projetos de software continuam com os mesmos
problemas nos dias atuais. Quer dizer, um problema detectado na dcada de
1960, quando a tecnologia que apoiava era praticamente inexistente, perpetuado at os dias atuais, com toda a tecnologia disposio.
A Standish Group, uma empresa que trabalha principalmente com projetos de software, publicou em 2009 um artigo chamado Chaos Report
captulo 4
103
(Relatrio do Caos), segundo o site Project Smart (Dominguez, 2009). Esse relatrio uma publicao frequente e realizada bianualmente. No artigo que
faz referncia ao relatrio de 2009 foi ressaltado que os projetos considerados
com sucesso cairam de 36% para 32% entre os dados de 2009 e 2002. Observe
a tabela 4.1 obtida do artigo:
SUCCESFUL
CHALLENGED
FAILED
1994
1996
1998
2000
2002
2004
2006
2009
16%
27%
26%
28%
34%
29%
35%
32%
53%
33%
46%
49%
51%
53%
46%
44%
31%
40%
28%
23%
15%
18%
19%
24%
Tabela 4.1 Evoluo da taxa de sucesso, falhas e mudanas. Fonte: DOMINGUEZ (2009).
60%
50%
53%
53%
40%
49%
51%
53%
46%
46%
34%
30%
31%
33%
27%
20%
28%
28%
32%
29%
26%
24%
23%
16%
15%
10%
44%
35%
18%
19%
Succesful
Challenged
Failed
0%
1994
1996
1998
2000
2002
2004
2006
2009
104
captulo 4
Tipo 2 ou Challenged (Mudana) o projeto finalizado e fica operacional, mas estoura o oramento e o prazo e oferece algumas das caractersticas
inicialmente propostas.
Tipo 3 ou Fracasso o projeto literalmente fracassa ou at mesmo
cancelado.
Os relatrios apresentados pelo Standish Group so muito teis para uma anlise histrica desses fatos. De qualquer forma, um valor quantitativo e isso importantes para
considerar qualquer tipo de anlise. Porm, h quem os critique devido aos critrios
que so utilizados para a elaborao desses relatrios. O artigo The Rise and Fall of
the Chaos Report Figures (EVELEENS & VERHOEF, 2010) um exemplo desses crticos. Segundo os autores, o Standish Group corrompe os dados e os torna unilaterais,
confundem as prticas usadas nas estatsticas e, consequentemente, os resultados se
tornam errados. Os crticos alegam que os dados que o Standish Group apresentam
no so validados, pois no so divulgadas suas origens. Ento, a nica forma de validar
os dados obter outra amostra e realizar a pesquisa novamente. Porm, mesmo com
estas questes, os dados do Chaos Report so teis como informaes de referncia
e histrico.
captulo 4
105
Portanto, com base no que foi visto at agora, e contextualizando os problemas da poca que vimos, uma forma de controlar a crise do software, de
acordo com Bauer, seria o estabelecimento de usos da engenharia tradicional
no desenvolvimento de software. Surgiu a primeira definio de Engenharia
de Software e esta utilizada at hoje: O estabelecimento e o uso de slidos
so os princpios de engenharia para que se possa obter economicamente um
software que seja confivel e que funcione eficientemente em mquinas reais
(BAUER, 1977).
106
captulo 4
Definio de
requisitos
Projeto de sistema
e software
Implementao e
teste de unidade
Integrao e teste
de sistema
Operao e
manuteno
captulo 4
107
O modelo em cascata importante porque ele serve de inspirao e referncia para outros modelos, inclusive os mais modernos. Atualmente ainda
bastante lgico utiliz-lo e muitas equipes ainda o adotam.
Este modelo orientado para a documentao detalhada de cada etapa. A
documentao no compreende apenas componentes textuais, mas sim representaes grficas de modelos de processo, banco de dados, responsabilidades
e at mesmo algumas simulaes.
Os nomes das etapas do modelo em cascata apresentados na figura 4.2 podem mudar de autor para autor, porm como vimos, as etapas so lineares:
uma realizada aps a finalizao da antecedente, e isto pode ser considerada uma desvantagem do modelo. Observando a figura 4.2, se os requisitos no
estiverem muito bem elaborados e claros, as demais fases estaro seriamente
comprometidas.
Alm disso, os requisitos, dependendo do projeto, esto em constante mudana, Logo, a etapa de requisitos no pode ficar muito tempo parada enquanto o desenho e implementao do sistema so completados. Ento, como mostra a figura 4.2, as setas que voltam para as etapas iniciais servem como um
feedback e forma de melhoria.
Porm, a constante interao descaracteriza o modelo em cascata. A ideia
inicial do modelo ser linear, mas como foi dito, existem as variaes do modelo que permitem interaes. As revises e avaliaes proporcionadas pelo
feedback comentado acima referem-se ao processo e no necessariamente proveniente de usurios.
Mesmo sendo um modelo bastante popular, pode-se apontar algumas limitacoes apresentadas por este modelo:
o modelo assume que os requisitos sao inalterados ao longo do desenvolvimento; isto, em boa parte dos casos, nao e verdadeiro, uma vez que nem todos
os requisitos sao completamente definidos na etapa de analise;
muitas vezes, a definicao dos requisitos pode conduzir a definicao do hardware sobre o qual o sistema vai funcionar; dado que muitos projetos podem
levar diversos anos para serem concluidos; estabelecer os requisitos em termos
de hardware e um tanto temeroso, dadas as frequentes evolucoes no hardware;
o modelo impoe que todos os requisitos sejam completamente especificados antes do prosseguimento das etapas seguintes; em alguns projetos, e
108
captulo 4
captulo 4
109
a) Modelo cascata
$
Planejamento
Analise
Desenho e
modelagem
Codificao
Teste
Entrega
3 - 24 meses
b) Processo iterativo
1 - 3 meses
1 - 3 meses
Entrega
Teste
Codificao
Desenho
Anlise
$
Planejamento
Entrega
Teste
Codificao
Desenho
Anlise
$
Planejamento
Entrega
Teste
Codificao
Desenho
Anlise
Planejamento
1 - 3 meses
$ = Entrega potencial
Figura 4.3 Esquema comparativo entre o modelo cascata (a) e o processo iterativo (b).
Fonte: Shore e Warden (2008, p. 35) (Adaptado pelo autor).
O desenvolvimento incremental foi proposto por H. Mills em 1980 como forma de reduo do retrabalho no processo de desenvolvimento e por permitir que
os requisitos pudessem ser definidos em outro momento, sem a necessidade de
ter a definio completa logo no incio do projeto (SOMMERVILLE, 2006, p.43).
Nesta abordagem, o desenvolvimento incremental possui algumas caractersticas marcantes, como, por exemplo, o desenvolvimento do sistema por
partes; classificao dos requisitos por ordem de prioridade, identificados pelos clientes; definio do nmero e tamanho dos incrementos; utilizao do
processo de desenvolvimento preferido para estes incrementos e adio de um
novo requisito cada novo incremento, conforme pode ser visto no esquema da
figura 4.4.
Define requisitos
preliminares
Desenvolve
incremento
Estabelece no de
incrementos
Valida o
incremento
Atribui requisitos
aos incrementos
Integra
incremento
Projeta arquitetura
do sistema
Valida o
sistema
Sistema
final
Sistema incompleto
110
captulo 4
111
importantes passem pela maior parte dos testes. Isso significa que menos
provvel que os clientes encontrem falhas de software na parte mais importante do sistema.
Marcoratti (2004) tambm apresenta algumas vantagens do processo incremental e iterativo:
Possibilidade de avaliar mais cedo os riscos e pontos crticos do projeto, e
identificar medidas para os eliminar ou controlar;
Reduo dos riscos envolvendo custos a um nico incremento. Se a equipe que desenvolve o software precisar repetir a iterao, a organizao perde
somente o esforo mal direcionado de uma iterao, no o valor de um produto
inteiro;
Definio de uma arquitetura que melhor possa orientar todo o
desenvolvimento;
Disponibilizao natural de um conjunto de regras para melhor controlar
os inevitveis pedidos de alteraes futuras;
Permite que os vrios intervenientes possam trabalhar mais efetivamente
pela interao e partilha de comunicao da resultante.
No entanto, o desenvolvimento incremental tambm possui alguns problemas ou pontos que devem ser considerados. Incrementos devem ser pequenos,
com menos de 20 mil linhas de cdigo, sendo que cada incremento deve realizar pelo menos um servio e isto pode ser difcil, pois no simples mapear os
requisitos exigidos em incrementos e com o nmero certo do tamanho. Outro
ponto que os requisitos s so detalhados no momento em que os incrementos so desenvolvidos, sendo difcil identificar facilidades comuns que todos os
incrementos tenham como exigncia.
De acordo com Wikipedia (2015), os dois padres mais conhecidos de sistemas iterativos de desenvolvimento so o RUP (Processo Unificado da Rational) e
o Desenvolvimento gil de software. Por isso o desenvolvimento iterativo e incremental tambm uma parte essencial da Programao Extrema (XP) e outros.
Como sabemos, o desenvolvimento de um produto complexo de software, no
meio comercial, pode levar meses, em torno de um ano ou at um pouco mais.
Assim, dividir o trabalho por meio de iteraes e partes menores mais prtico,
resultando em incrementos a cada iterao (repetio de uma ou mais aes).
112
captulo 4
Anlise
Desenho
Teste
Anlise
2a verso
Desenho
Codificao
Teste
Manuteno
Figura 4.5 Abordagem incremental. Fonte: MARCORATTI (2014) (Adaptado pelo autor).
captulo 4
113
vezes isto requer um novo tipo de contrato e a isto pode ser um entrave para
grandes clientes, como rgos de governo, que geralmente no aceitam este
tipo de contrato ou esta abordagem (SOMMERVILLE, 2006, p.43).
Os mtodos geis possuem foco maior nos resultados do que nos processos,
e isto pode torn-los mais leves, no entanto importante observar que isto no
os classifica como um modelo de processos simplistas ou menos complexos.
Os principios dos modelos ageis foram claramente colocados no Manifesto
agil e assinados por 17 pesquisadores da area, entre os quais Martin Fowler,
Alistair Cockburn e Robert Martin. O manifesto estabelece o seguinte
(WAZLAWICK, 2013, p. 77):
Nos estamos descobrindo formas melhores de desenvolver software fazendo e ajudando outros a fazer. Atraves desse trabalho chegamos aos seguintes
valores:
Individuos e interacoes estao acima de processos e ferramentas.
Software funcionando esta acima de documentacao compreensivel.
Colaboracao do cliente est acima de negociacao de contrato.
Responder as mudancas esta acima de seguir um plano.
Ou seja, enquanto forem valorizados os primeiros, os outros valerao
mais.
114
captulo 4
nao sao construidos por uma unica pessoa, eles sao construidos por uma equipe, entao
elas precisam trabalhar juntas (incluindo programadores, testers, projetistas e tambem o
cliente). Processos e ferramentas sao importantes, mas nao sao tao importantes quanto
trabalhar juntos.
2.
deve existir para ajudar pessoas a entender como o sistema foi construido, mas e muito
mais facil entender o funcionamento vendo o sistema funcionar do que atraves de diagramas que descrevem o funcionamento ou abstraem o uso.
3.
pode dizer o que ele espera do software, e normalmente eles nao sabem explicar exatamente o que eles esperam, e ainda eles mudam de ideia ao longo do tempo e conforme
eles vem o software funcionando. Ter um contrato e importante para definir as responsabilidades e direitos, mas nao deve substituir a comunicacao. Trabalhos desenvolvidos com
sucesso tem constante comunicacao com o cliente para entender suas necessidades e
ajud-lo a descobrir a melhor forma de express-las.
4.
ambiente de negocios e elas acontecem por inumeras razoes: as regras e as leis sofrem
alteracoes, as pessoas mudam de ideia e a tecnologia evolui. O software precisa refletir
essas mudancas. Um projeto de software certamente deve ter um plano, mas ele deve
ser flexivel o suficiente para comportar as mudancas quando elas aparecerem, senao ele
se torna irrelevante.
LIBARDI, 2010, p.2.
Para os modelos geis, a valorizao de processos, ferramentas, documentao, planos e contratos ter mais sentido e mais valor depois que indivduos,
interaes, colaboraes do cliente, software funcionando e resposta s mudanas forem considerados tambm importantes. De forma, nota-se que processos bem estruturados de nada adiantam se as pessoas no os seguirem, da
mesma forma que um software bem documentado tambm no adianta se este
no satisfaz os requisitos exigidos pelo cliente ou se estes no funcionam, e
assim por diante.
captulo 4
115
116
captulo 4
captulo 4
117
Ainda de acordo com Pressman, (2011, p.82), qualquer processo agil de sof-
tware e caracterizado de uma forma que se relacione a uma serie de preceitoschave acerca da maioria dos projetos de software:
1. E dificil afirmar antecipadamente quais requisitos de software irao persistir e quais sofrerao alteracoes. E igualmente dificil prever de que maneira as
prioridades do cliente sofrerao alteracoes conforme o projeto avanca.
2. Para muitos tipos de software, o projeto e a construcao sao interconduzidos . Ou seja, ambas as atividades devem ser realizadas em sequencia (uma
atras da outra), para que os modelos de projeto sejam provados conforme sejam
criados. E dificil prever quanto de trabalho de projeto ser necessario antes que
a sua construcao (desenvolvimento) seja implementada para avaliar o projeto.
118
captulo 4
3. Analise, projeto, construcao (desenvolvimento) e testes nao sao tao previsiveis (do ponto de vista de planejamento) quanto gostariamos que fosse.
Esses trs pontos levantam questionamentos bem pertinentes: como administrar a imprevisibilidade por meio de processos? Como estes processos poderiam ser criados? A adaptao destes processos o caminho a ser percorrido,
portanto, um processo gil deve ser adaptvel. Estas adaptaes podem ocorrer
de maneira incremental e para que isto acontea, necessrio colher feedbacks
do cliente, por parte das equipes geis.
Ao longo da histria da engenharia de software, surgiram dezenas de metodologias e descries de processos, mtodos e notaes de modelagem, ferramentas e tecnologias obsoletas. Algumas tiveram maior adeso que outras
e outras foram sendo ofuscadas pelo surgimento de novas entrantes, supostamente melhores. Com o surgimento de vrios modelos de processos geis, a
histria seguindo o mesmo caminho que antes, onde notamos disputas pela
aceitao das novas metodologias ou daquelas que se concretizaram na opinio da comunidade de desenvolvimento de software.
Dentre estes modelos, o Extreme Programming (XP) o mais amplamente utilizado. No entanto, muitos outros tm sido propostos e encontram-se em
uso no setor, conforme relaciona Pressmann (2011, p. 93), apontando os mais
comuns:
Desenvolvimento de software adaptativo (Adaptive Software Development,
ASD)
Scrum
Metodo de desenvolvimento de sistemas dinamicos (Dynamic Systems
Development Method, DSDM)
Crystal
Desenvolvimento dirigido a Funcionalidades (Feature Drive Development,
FDD)
Desenvolvimento de software enxuto (Lean Software Development, LSD)
Modelagem agil (Agile Modeling, AM)
Processo unificado agil (Agile Unified Process, AUP)
captulo 4
119
SIMPLICIDADE
RESPEITO
COMUNICACAO
FEEDBACK
CORAGEM
120
captulo 4
A XP preconiza mudanas incrementais e feedback rpido, alm de considerar a mudana algo positivo, que deve ser entendido como parte do processo
desde o incio. Alm disso, a XP valoriza o aspecto da qualidade, pois considera
que pequenos ganhos a curto prazo pelo sacrifcio da qualidade no so compensados pelas perdas a mdio e a longo prazo (WAZLAWICK, 2013, p. 99).
Iterao
Iterao
Iterao
Iterao
$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
Anlise
Desenho
Codificao
Entrega
Planejamento
$ = Entre potencial
Teste
1 semana
Figura4.6CiclodevidaXP.Fonte:ShoreeWarden(2008,p.35)(Adaptadopeloautor).
Dentre as caractersticas desta abordagem, a priorizao de funcionalidades mais importantes proporciona entregas parciais daquilo que mais importante, mesmo que todo o trabalho do projeto ainda no tenha sido concludo.
De acordo com Soares (2014, p. 3), o primeiro projeto a usar XP foi o C3, da
Chrysler. Aps anos de fracasso utilizando metodologias tradicionais, com o
uso da XP o projeto ficou pronto em pouco mais de um ano.
A XP baseia-se nas 12 prticas apresentadas por Beck (1999) a seguir
(SOARES, 2014, p. 4):
1. Planejamento (Jogo de planejamento): consiste em decidir o que necessrio ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, no em requisitos futuros. Alm
disso, a XP procura evitar os problemas de relacionamento entre a rea de negcios (clientes) e a rea de desenvolvimento. As duas reas de vem cooperar para
o sucesso do projeto e cada uma deve focar em partes especficas do projeto.
121
captulo 4
Desta forma, enquanto a rea de negcios deve decidir sobre o escopo, a composio das verses e as datas de entrega, os desenvolvedores devem decidir
sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma
detalhado para que o software seja entregue nas datas especificadas.
2. Entregas freqentes: visa construo de um software simples, e conforme os requisitos surgem, h a atualizao do software. Cada verso entregue
deve ter o menor tamanho possvel, contendo os requisitos de maior valor para
o negcio. Idealmente devem ser entregues verses a cada ms, ou no mximo
a cada dois meses, aumentando a possibilidade de feedback rpido do cliente.
Isto evita surpresas caso o software seja entregue aps muito tempo e melhora
as avaliaes do cliente, aumentando a probabilidade do software final estar de
acordo com os requisitos do cliente.
3. Metfora: so as descries de um software sem a utilizao de termos
tcnicos, com o intuito de guiar o desenvolvimento do software.
4. Projeto simples: o programa desenvolvido pelo mtodo XP deve ser o
mais simples possvel e satisfazer os requisitos atuais, sem a preocupao de
requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim
que eles realmente existirem.
5. Testes: a XP focaliza a validao do projeto durante todo o processo de
desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes.
6. Programao em pares: a implementao do cdigo feita em dupla,
ou seja, dois desenvolvedores trabalham em um nico computador. O desenvolve dor que est com o controle do teclado e do mouse implementa o cdigo, enquanto o outro observa continuamente o trabalho que est sendo feito,
procurando identificar erros sintticos e semnticos e pensando estrategicamente em como melhorar o cdigo que est sendo implementado. Esses papis podem e devem ser alterados continuamente. Uma grande vantagem da
programao em dupla a possibilidade de os desenvolvedores estarem continuamente aprendendo um com o outro.
7. Refatorao: focaliza o aperfeioamento do projeto do software e
est presente em todo o desenvolvimento. A refatorao deve ser feita apenas quando necessrio, ou seja, quando um desenvolvedor da dupla, ou os
dois, percebe que possvel simplificar o mdulo atual sem perder nenhuma
funcionalidade.
122
captulo 4
captulo 4
123
4.4.2 Scrum
O Scrum um framework gil utilizado para auxiliar o gerenciamento de projetos considerados complexos, bem como no desenvolvimento de produtos,
de maneira incremental e iterativa. muito utilizado em desenvolvimento de
softwares por ter um conjunto de prticas leves e objetivas (PRIKLADNICKI et
al., 2014, p. 22).
Diferente da grande maioria das outras metodologias que abordam o desenvolvimento a partir das tarefas de programao de modo explcito, o Scrum
voltado para o gerenciamento dos projetos de software. O seu uso em conjunto com outras metologias, como o XP, por exemplo, proporcionam resultados bem interessantes, conforme afirma Oliveira (2003, p. 24). O fato de ser um
framework, sendo um conjunto de prticas estruturadas e sistematizadas, facilita esta associao e complemento a outras metodologias.
A concepcao inicial do Scrum deu-se na industria automobilistica , e o modelo pode ser adaptado a diferentes areas da producao de software (WAZLAWICK,
2013, p. 92). O seu nome foi inspirado a partir de uma jogada existente no
rugby, chamada Scrum e, portanto, no uma sigla. comum ainda encontrarmos por a a associao de Scrum como uma metodologia de desenvolvimento
124
captulo 4
captulo 4
125
126
captulo 4
captulo 4
127
24 horas
30 dias
Product Backlog
Scrum
Master
Sprint Backlog
Sprint
Product
Owner
Software
Equipe
Figura4.7EstruturadoScrum.Wikimedia.Disponvelem:<http://upload.wikimedia.org/
wikipedia/commons/5/58/Scrum_process.svg>.
128
captulo 4
Figura 4.8 Quadro de acompanhamento de uma Sprint, tambm conhecido por Kanban.
Wikimedia. Disponvel em: <http://commons.wikimedia.org/wiki/File:Scrum_task_board.jpg>
captulo 4
129
25
Remaining and completed tasks
250
200
20
150
15
100
10
5
50
0
Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Completed tasks
Remaining effort
Ideal burndown
Remaining tasks
130
captulo 4
ATIVIDADES
01. Explique o que e para que serve um ciclo de vida do software?
02. Pesquise sobre o manifesto gil e descreva 5 principais caractersticas das metodologias geis.
03. Considerando que um projeto de desenvolvimento de software esteja utilizando o modelo cascata como metodologia escolhida, comente como este projeto reagiria com a indefinio de requisitos e mudanas ao longo do processo de desenvolvimento.
captulo 4
131
REFLEXO
Afinal, qual seria o melhor mtodo de desenvolvimento ou modelo de ciclo de vida
de software?
Ao estudar este captulo, eventualmente voc pode ter questionado esta pergunta. Quando lidamos com diferentes paradigmas, ou diferentes formas de fazer valer cumprir o mesmo objetivo, que o de desenvolver softwares de qualidade, podemos nos encontrar em
situaes de dvidas sobre qual caminho seguir, em relao s diferentes abordagens e
metologias existentes. H uma srie de fatores que devem ser analisados e esta no uma
resposta simples, direta e to objetiva. Estes fatores podem estar relacionados com a qualidade dos requisitos de sistema, grau de maturidade da equipe, tamanho da equipe, grau do
envolvimento e acesso ao cliente, entre outros.
132
captulo 4
Deste modo, podemos observar que cada metodologia, cada modelo de ciclo de vida
de software possui suas peculiaridades e capacidades, e podemos e devemos fazer alguns
questionamentos, como, por exemplo, se o projeto de software em questo trabalha com a
compreenso deficiente dos requisitos; trabalha com a compreenso deficiente da qualidade;
produz sistemas de alta confiana; ser fcil modificar o sistema em verses futuras; gerencia riscos; pode ser alimentado em um cronograma predefinido; permite correes no meio
do projeto; possibilita ao cliente visibilidade do progresso; possibilita ao cliente visibilidade do
progresso do gerenciamento; requer pouca gerncia ou experincia para us-lo.
Com estes e outros questionamentos, podemos analisar alguns fatores que podero
contribuir para a escolha do mtodo de desenvolvimento que melhor se adequar equipe
de desenvolvimento e a todos os envolvidos neste processo.
LEITURA
Existem vrias recomendaes para os tpicos apresentados neste captulo.
Como publicao impressa, o livro de Roger Pressman, 2011, fundamental e uma excelente referncia para a rea, assim como os livros de Shari L. Pfleeger.
PFLEEGER, S. L. Engenharia de Software - Teoria e Prtica. So Paulo: Prentice
Hall, 2010
PRESSMAN, R. Engenharia de Software. So Paulo: McGraw-Hill, 2011.
Em seu livro, Pressman ainda sugere livros como os de Shaw e Warden (The Art of Agile
Development, OReilly Media, Inc., 2008), Hunt (Agile Software Building, Springer, 2005) e
Carmichael e Haywood (Better Software Faster, Prentice-Hall, 2002), que trazem discussoes
interessantes sobre o tema. Aguanno (Managing Agile Projects, Multi-Media Publications,
2005), Highsmith (Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004) e Larman (Agile and Iterative Development: A Managers Guide, Addison-Wesley,
2003) apresentam uma visao geral sobre gerenciamento e consideram as questoes envolvidas no gerenciamento de projetos. Highsmith (Agile Software Development Ecosystems,
Addison-Wesley, 2002) retrata uma pesquisa de principios, processos e praticas ageis. Uma
discussao que vale a pena sobre o delicado equilibrio entre agilidade e disciplina e fornecida
por Booch e seus colegas (Balancing Agility and Discipline, Addison-Wesley, 2004).
captulo 4
133
REFERNCIAS BIBLIOGRFICAS
BECK, K. Programao Extrema Explicada. Bookman, 1999. p. 182.
CHARETTE, R. Fair Fight? Agile Versus Heavy Methodologies, Cutter Consor- tium E-project
Management, Advisory Service, 2, 13, 2001.
LIBARDI, P. L. O; BARBOSA, V. Mtodos geis. Faculdade de Tecnologia - FT, Limeira. UNICAMP.
2010. p. 24.
MARCORATTI. O processo de Software, 2014. Disponvel em: <http://www.macoratti.net/proc_sw1.
htm>. Acesso em: 28 nov. 2014.
MAZZOLA, V. B. Engenharia de Software - Conceitos Bsicos, Apostila, 2010. Disponvel em:
<https://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf>. Acesso em: 17
dez. 2014.
OLIVEIRA, E. S. Uso de Metodologias geis no Desenvolvimento de Software. Monografia.
UFMG. Belo Horizonte. 2003. p. 36.
PRESSMAN, R. S. Engenharia de Software, 7 edio. So Paulo: McGraw-Hill, 2011. p. 780.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F.; Mtodos geis para desenvolvimento de software. Porto
Alegre: Bookman, 2014. p. 311.
SILVA, B. C. C. Integrando Agilidade com maturidade. Revista Engenharia de Software Magazine.
Ed. 59. Disponvel em: <http://www.devmedia.com.br/integrando-agilidade-com-maturidade-revistaengenharia-de-software-magazine-59/28197>. Acesso em: 16 dez. 2014.
SHORE, J.; WARDEN, S.; The Art of Agile Development. O Reilly Media. 2008. 411p.
SOARES, M. S. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento
de Software. Unipac Universidade Presidente Antnio Carlos, Faculdade de Tecnologia e Cincias
de Conselheiro Lafaiete. Disponvel em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>.
Acesso em: 15 dez. 2014.
SOMMERVILLE, I. Engenharia de Software, 6. ed.. Editora Pearson do Brasil, 2003. p. 292.
SOMMERVILLE, I. Engenharia de Software, 7. ed. Editora Pearson do Brasil, 2007.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1. ed.., Elsevier, 2013. 506p.
WIKIPDIA. Desenvolvimento iterativo e incremental. Disponvel em: <http://pt.wikipedia.org/wiki/
Desenvolvimento_iterativo_e_incremental>. Acesso em: 17 jan. 2015.
134
captulo 4
5
Processo Unificado
(UP)
OBJETIVOS
conhecer o processo unificado e suas fases;
aprender sobre o ciclo de vida do processo unificado;
conhecer o processo RUP;
conhecer o processo de desenvolvimento PRAXIS;
conhecer o que uma ferramenta CASE;
obter o melhor desempenho de sua equipe de desenvolvimento atravs de utilizao e
integrao entre ferramentas CASE.
136
captulo 5
captulo 5
137
Nosso apetite por software cada vez mais sofisticado aumenta a medida que tomamos
conhecimento de uma versao do produto para a seguinte, como o produto pode ser
aperfeicoado. Queremos software que seja mais e mais adaptado a nossas necessidades, mas isso, por sua vez, simplesmente torna o software mais complexo. Em suma,
queremos cada vez mais.
PRESSMAN, 2011, p. 71
No processo unificado a comunicacao com o cliente e os metodos racionalizados (sequencializados) para descrever a visao do cliente sobre um sistema (
casos de uso) so considerados essenciais. H nfase na arquitetura de software, auxiliando na manuteno do foco nas metas corretas, tais como compreensibilidade, confianca em mudancas e reutilizacao. O fluxo de processo deve
ser iterativo e incremental, proporcionando a sensacao evolucionaria que e
essencial no desenvolvimento de software moderno (PRESSMAN, 2011, p. 72).
As atividades do UP sao bem definidas no seguinte sentido (WAZLAWICK,
2013, p. 119):
a)
b)
c)
d)
e)
f)
138
captulo 5
captulo 5
139
CONEXO
Seguem alguns links de ferramentas que so utilizadas no processo unificado e que esto
relacionadas com os assuntos tratados neste captulo:
System Architect: http://migre.me/oHSyr
Rational Rose: http://migre.me/oHSxQ
Oracle Designer: http://migre.me/oHSx3
GDPro:
Iterao
#2
Elaborao
...
...
Construo
...
...
Transio
...
Iterao
n1
Verses
140
captulo 5
Iterao
n...
Cada ciclo consiste de quatro fases: incio, elaborao, construo e transio. Cada fase tambm subdividida em iteraes, como discutido anteriormente (figura 5.1).
Estas 4 fases, subdivididas em iteraes, passam por cinco fluxos de trabalho (Workflow): Requisitos, Anlise, Projeto, Implementao e Teste. A figura
a seguir mostra um grfico deste fluxo, tambm conhecido como grfico das
baleias (CANZ, 2014).
Fases
Fluxos de trabalho
Concepo
Elaborao
Transio
Construo
Requisitos
Uma iterao
na fase de Elaborao
Anlise
Projeto
Implementao
Teste
Iteraes
preliminares
#1
#2
#n
#n+1
#+2
#m
#m+1
Iteraes
141
captulo 5
Os requisitos mais importantes so identificados durante a fase de concepo. Na fase de elaborao, os requisitos remanescentes so analisados,
possibilitando a compreenso real do tamanho do sistema. Ao final da fase de
elaborao, a maior parte dos requisitos do sistema devem ter sido descritos,
no entanto apenas 10% destes requisitos so implementados nesta fase. Eles
sero identificados e implementados durante a fase de construo. J na fase
de transio quase no h requisitos a serem identificados, a menos que ocorram alteraes nos requisitos (Canz, 2014).
O fluxo (ou workflow) de requisitos tem como objetivo planejar o desenvolvimento em direcao ao sistema correto. Busca, assim:
I. Entender o contexto do sistema
II. Para expressar o contexto de um sistema, o gerente de projeto define: um
modelo do dominio; um modelo do negocio (casos de uso e objetos do negocio).
III. Enumerar os requisitos candidatos
IV. Ideias mencionadas pelos clientes, usuarios, analistas e desenvolvedores sao enumeradas como requisitos candidatos.
V. Capturar os requisitos funcionais (atraves de casos de uso)
1. Identificar os atores e casos de uso (diagramas de casos de uso)
2. Dar prioridades aos casos de uso
3. Detalhar os casos de uso
4. Definir a interface com o usuario
a) projeto da interface logica: elementos que representam os atributos dos casos de uso.
b) projeto e prototipo da interface fisica: sketches com
os elementos identificados na interface logica. Prototipos
executaveis sao construidos para as partes mais importantes e onde a usabilidade deve ser avaliada.
VI. Capturar os requisitos nao funcionais
142
captulo 5
captulo 5
143
144
captulo 5
I.
145
O fluxo de implementao tem maior importncia durante a fase de construo. H maior simplicidade neste fluxo, pois as decises mais difceis j
foram tomadas durante a etapa de fluxo de projeto. O cdigo gerado durante
a implementao deve ser uma simples traduo das decises de projeto em
uma linguagem especifica (CANZ, 2014).
O fluxo (ou workflow) de Implementao: tem como objetivo implementar
o sistema a partir do resultado do projeto. Busca, assim:
I.
146
captulo 5
Durante o fluxo de teste gerado o modelo de teste, esse modelo descreve como
componentes executveis, provenientes do fluxo de implementao, sero testados.
No modelo de testes pode vir descrito com os aspectos especficos do sistema sero
testados, como, por exemplo, se a interface como o usurio simples e consistente ou
se o manual de usurio cumpre o seu objetivo. Resumindo, o papel do fluxo de teste
verificar se os resultados do fluxo de implementao cumprem os requisitos estipulados por clientes e usurios, para decidir se o sistema necessita de revises ou se o
processo de desenvolvimento pode continuar (CANZ, 2014).
O fluxo (ou workflow) de teste: tem como objetivo testar o resultado da implementao. Busca, assim:
I. Planejar e projetar o teste (projetista de teste)
1. Planejamento dos testes de uma iteracao: como e quando rodar, quando terminar os testes, estimar os recursos humanos e de sistema necessarios, agendar os testes.
II. Os casos de testes sao baseados nos diagramas de iteracao dos casos de
uso.
III. Implementar o teste (engenheiro de componente)
IV. Executar o teste de integracao (testador de integracao)
V. Executar o teste de sistema (testador de sistema)
VI. Avaliar o teste (projetista de teste)
captulo 5
147
Como muito apoiado em ferramentas CASE, vamos passar pelos principais tpicos existentes.
O RUP usa a orientao a objetos em sua concepo e projetado e documentado com a UML (Unified Modeling Language) para ilustrar os processos em
ao.
Atualmente, o RUP controlado e mantido pela IBM, porm sua origem
se deve empresa Rational, que conseguiu muito destaque no mercado mundial por ter uma metodologia bastante consistente aliada a uma ferramenta
que a suportava inteiramente (o Rational Rose). Sendo assim, e por ser adotado em vrias empresas no mundo todo, usa tcnicas e prticas aprovadas
comercialmente.
Segundo o site da IBM (IBM, 2012) e Sommerville (2007), o RUP utiliza seis
prticas como linha de base nos ciclo de produo. So elas:
GESTO DE REQUISITOS
ARQUITETURA BASEADA EM
COMPONENTES
DESENVOLVIMENTO INTERATIVO
148
captulo 5
contm os workflows necessrios que as partes interessadas (stakeholders) concordem com os objetivos,
CONCEPO
(INCEPTION)
ELABORAO
(ELABORATION)
CONSTRUO
(CONSTRUCTION)
TRANSIO
(TRANSITION)
captulo 5
149
Phases
Workflows
Inception
Elaboration
Construction
Transition
Bussiness modeling
Requirementes
Analysis & design
Implementation
Test
Dimenso espacial
Deployment
Configuration
& Change mgmt
Project Management
Environment
Initial
Elab #1
Elab #2
Dimenso temporal
Const
#1
Const
#2
Const
Tran #1 Tran #2
#N
Iterations
CONEXO
A seguir, apresentamos alguns links a respeito do processo RUP:
http://www.wthreex.com/rup/portugues/index.htm. Excelente material on-line sobre o
processo RUP, com todos os seus conceitos e caractersticas
http://www-01.ibm.com/software/awdtools/rup/. Em ingls. Site da IBM contendo vrios
links sobre RUP e sua integrao com as ferramentas de software da IBM. Vale a pena dar
uma olhada.
http://javafree.uol.com.br/artigo/871455/;. Este artigo relaciona qualidade de software,
vista nas unidades anteriores, com o processo RUP.
150
captulo 5
WORKFLOWS
TAREFAS
MODELO DE
EQUIPE
descritos detalhadamente. Cada papel pode ser representado por mais de um ator ou um ator pode ter mais de
um papel, dependendo da carga de trabalho necessrio.
Ao todo so mais de 30 tipos de papis.
MODELOS DE
DOCUMENTOS
captulo 5
151
5.4.3 PRAXIS
O Praxis, apresentado por Paula Filho (2001), e um processo de desenvolvimento de software baseado no processo unificado. Sua simplificacao serve de suporte a treinamentos de engenheiros de software.
O Prxis foi projetado para faciliar o ensino de processos de software. Tem,
assim, enfoque educacional, busca dar suporte ao treinamento em Engenharia
152
captulo 5
153
5.5.1 Histrico
Apenas no incio da dcada de 1980 que surgiram no mercado as primeiras
ferramentas que se consideram atualmente como CASE. O Excelerator, uma
das primeiras ferramentas CASE unanimemente considerada como tal, surgiu
154
captulo 5
em 1984. A crescente importncia que foram tendo no processo de desenvolvimento est diretamente relacionada com um conjunto de fatores decisivos que
contriburam para o crescente sentimento da necessidade deste tipo de ferramentas. Veja a seguir:
A mudana de nfase das atividades de programao para atividades de
anlise e desenho de software, de modo a superar os diversos problemas dos
mtodos de trabalho ad-hoc.
Utilizao de computadores pessoais e de interfaces de trabalhos grficos.
O aparecimento de diversas tcnicas de modelagem de sistemas, que implicavam no desenho de diagramas grficos (tais como os fluxogramas ou diagramas de fluxos de dados), em que a representao destas notaes em papel,
ou em textuais, tornava-se impraticvel medida que a respectiva complexidade aumentava.
O aumento da complexidade e do tamanho do software, associado s
maiores capacidades do hardware.
No incio dos anos 1990, muitas das ferramentas CASE passaram a ser designadas por ferramentas RAD (Rapid Application Development), o que traduzia a preocupao de aumentar o ritmo do desenvolvimento de aplicaes.
Exemplos destas ferramentas foram (e algumas ainda so) o Visual Basic, Sql
Windows, Dephi, Powerbuilder, Oracle Designer e Oracle Developer, que so
frequentemente utilizadas para auxiliar o desenvolvimento de software para
ambientes cliente-servidor. A figura 5.4 apresenta a evoluo das ferramentas.
Ferramentas de
desenvolvimento
Ferramentas de
desenvolvimento
Editores de texto
Compiladores
Interpretadores
Linkers
DFDs
ERs
Esquemas de BDs
Documentao
Ferramentas
RAD
Gerao de cdigo
Realizao de testes
Gesto de projetos
Ambientes
integrados de
modelagem visual
Integrao
Modelagem OO
Modelagem de negcio
A partir de meados dos anos 1990, com a crescente importncia das abordagens orientadas a objetos e o desenvolvimento de componentes, a terminologia
utilizada por alguns autores passou a ser ferramentas de modelagem visual. No
entanto, a expresso CASE permanece, no nosso entender, como a mais abrangente de todas.
captulo 5
155
156
captulo 5
A arquitetura tpica das ferramentas CASE (ou pelo menos uma que se considera mais adequada para este tipo de aplicaes) constituda por um conjunto de aplicaes/componentes, suportados por um repositrio integrado.
Na prtica, o papel do repositrio pode ser concretizado atravs de uma
base de dados, como o caso tpico dos fornecedores que possuem simultaneamente produtos CASE e bases de dados (casos da Oracle e da Sybase), mas
muitos produtos utilizam um simples sistema de gesto de arquivos, alguns
com formatos proprietrios.
O repositrio de uma ferramenta CASE particularmente relevante, uma
vez que facilita a gesto de modelos elaborados, e a respectiva reutilizao, disponibilizando, para isso, mecanismos potentes de pesquisa.
Tipicamente, o seu contedo incluir:
Templates de mbito variado, diagramas e documentos, que facilitam a
elaborao de artefatos concretos a partir de modelos genricos.
Templates e frameworks de aplicao, a partir dos quais podem ser construdos esqueletos de aplicaes em funo de um conjunto de parmetros.
Bibliotecas de objetos, classes e componentes, que alm de eventuais
componentes que possam vir inicialmente com as ferramentas, permitem a integrao de outros desenvolvidos ao longo do tempo.
Diagramas diversos que resultam da modelao do sistema.
Cdigo-fonte , programas executveis e aplicaes empacotadas prontas
para serem distribudas aos usurios finais.
Arquivos de dados para testes e scripts de execuo dos mesmos.
O repositrio apresenta as funcionalidades tpicas de um sistema de gesto
de bases de dados, no que diz respeito a:
Garantia de integridade de dados.
Partilha de informao.
Suporte ao trabalho concorrente de vrios utilizadores.
Facilidades de realizao de operaes de pesquisa.
O repositrio um componente crtico ao oferecer mecanismos e estruturas
de dados para a integrao entre as ferramentas, constituindo-se como o meio
de armazenamento comum, para todos os artefatos. Com objetivo de garantir o
captulo 5
157
CONEXO
Veja, a seguir, os links de algumas ferramentas citadas neste captulo:
System Architect: http://www-01.ibm.com/software/awdtools/systemarchitect/
Rational Rose: http://www-01.ibm.com/software/awdtools/developer/rose/
Oracle Designer: http://www.oracle.com/technetwork/developer-tools/designer/overview/index-082236.html
GDPro: http://www-d0.fnal.gov/computing/tools/gdpro/gdpro.html
Power Designer: http://www.sybase.com.br/products/modelingdevelopment/powerdesigner
Silverrun: http://www.silverrun.com/
ERWin: http://erwin.com/
Genexus: http://www.genexus.com/Inicio/inicio?pt
158
captulo 5
O CASE Data Interchange Format (CDIF) outra iniciativa desenvolvida nesta rea, conduzida pela Electronic Industries Association. O CDIF comeou a
ser desenvolvido em 1987, tendo sido originalmente publicado em 1991 e revisto em 1994 e em 1997, de forma a incorporar contributos posteriores. O CDIF
consiste numa famlia de padres, que definem: (1) uma arquitetura nica para
a troca de informao entre ferramentas de modelagem de diferentes fabricantes e (2) as interfaces entre os componentes que implementam esta arquitetura.
Durante a dcada de 1990, muitas ferramentas aderiram a este padro, mas
com a crescente utilizao das notaes orientadas a objetos e, em particular,
com o UML, perdeu sua importncia e sucesso que lhe eram atribudos inicialmente. Para isso, muito contribuiu para o desenvolvimento do XMI, como novo
padro de integrao entre ferramentas que suportam UML, e baseado em XML.
5.5.4 Taxonomia
A incluso de um produto no universo das ferramentas CASE depende da
abrangncia da definio considerada. Por exemplo, uma parte significativa
das pessoas teria dificuldade em considerar um simples editor de texto como
uma ferramenta CASE. Normalmente, pensamos sempre em ferramentas de
suporte a atividades mais nobres, e a edio de cdigo no traz aparentemente qualquer valor acrescentado ao desenvolvimento de software.
No entanto, se pensarmos no significado exato do termo, e que sem um
editor de texto no seria possvel produzir um programa (para alm de que ele
pode mesmo automatizar algumas tarefas, como sejam a substituio de palavras), seremos levados a reconsiderar e a inclu-lo nesta classificao.
Os critrios utilizados para classificar as ferramentas CASE so muito diversos. Os mais significativos incluem:
a anlise das funcionalidades disponveis;
o papel que representam para os gestores ou para elementos
tcnicos;
a possibilidade de serem utilizados nas vrias fases do processo de
desenvolvimento de software.
captulo 5
159
Uma primeira classificao das ferramentas CASE pode ser efetuada com
base nos seguintes critrios:
Fases do processo de desenvolvimento nas quais as ferramentas se
aplicam:
Ferramentas Upper-Case so aplicaes que se especializaram na fase de concepo do software (ferramentas de
anlise e especificao e/ou modelao de requisitos).
Ferramentas Lower-Case so aplicaes utilizadas na fase
de implementao (ferramentas de desenho tcnico, de
edio e compilao de cdigo e de testes).
Utilizao das ferramentas em atividades especficas de uma fase/
tarefa ou concebidas para atividades que se desenrolam ao longo
de todo o ciclo: um exemplo tpico das primeiras so as ferramentas
que implementam ambientes de desenvolvimento, enquanto que
nas segundas se pode incluir uma ferramenta de gesto de projetos.
Uma outra classificao mais detalhada agrupa as ferramentas nas seguintes categorias:
Modelagem de processos de negcio ferramentas orientadas
para a anlise e especificao dos processos de negcio, que permitem verificar como os objetivos estratgicos de negcio so concretizados nos processos. Alm de utilizarem diversas notaes e
diagramas para a representao de informao do negcio (cadeia
de valor, responsabilidades e funes da organizao), recorrem
com frequncia a tcnicas de simulao e anlise de custos. Estas
funcionalidades possibilitam a utilizao destas ferramentas para
compreender o funcionamento da empresa e identificar problemas ou oportunidades de melhoria (e no para o desenvolvimento
de software). Esta categoria muitas vezes no considerada como
ferramenta CASE.
Modelao de anlise e desenho do sistema esta a categoria
onde se pode incluir a maioria das ferramentas CASE. Permitem
normalmente relacionar modelos de processos com os modelos e
requisitos. nesta rea que o paradigma da orientao a objetos
e o UML tm tido maior impacto. Como exemplos desta categoria
160
captulo 5
temos o Rose, o Paradigm Plus, o GDPro. Se considerarmos as ferramentas que adicionalmente suportam abordagens estruturadas,
temos o System Architect, o PowerDesigner e o Silverrun.
Desenho de bases de dados aparecem na sequncia das ferramentas anteriores (muitas vezes de forma integrada), mas especializaram-se na definio lgica e fsica da estrutura das bases de dados.
Exemplos: System Architect, PowerDesigner e o Erwin.
Programao de aplicaes ferramentas que normalmente incluem num ambiente nico e integrado (se bem que as mais antigas
podem ainda funcionam de forma autnoma) funcionalidades de
edio de programas, de criao da interface, e outros programas,
tais como os interpretadores, compiladores, geradores de cdigo e
debuggers. Exemplos: Visual Studio, Eclipse, Delphi, Genexus.
Gesto de alteraes no software do suporte ao trabalho em
equipe, e implementam funcionalidades de gesto de verses, de
mecanismos de check-in e check-out (operaes que garantem que
apenas uma pessoa acesse com permisses de alterao a um determinado arquivo do sistema), de gesto da configurao e distribuio do software. Exemplos: SVN, CVS, Visual SourceSafe, Rational
Team Concert e ClearQuest.
Testes: esta categoria compreende ferramentas que permitem a
definio de regras de testes, a gerao de scripts para posterior
execuo de testes, a definio de dados para testes, o controle e a
gesto de erros, e a obteno de estatsticas relacionadas com esta
informao. Exemplos: Rational Test Lab Manager, Rational Test
Real-Time e TestWorks.
Orientadas para a Gesto de Projetos so ferramentas cujas principais funcionalidades se destinam a facilitar as tarefas de gesto
e coordenao dos projetos, com recursos que auxiliam no planejamento e estimativa de tempos, custos e recursos, utilizao de
recursos pelo projeto, definio de responsabilidades. Por vezes,
incluem ainda facilidades de auxlio na aplicao de uma metodologia de desenvolvimento de software (muitas vezes disponibilizando informao sobre melhores prticas, casos de estudo e uma base
de conhecimento sobre todo o processo). Exemplos: MS Project,
ProjectBuilder e Juggler.
captulo 5
161
162
captulo 5
captulo 5
163
Representao de diversos diagramas tpicos da gesto de projetos (diagramas de Pert, Gantt, matrizes de alocao de recursos).
Possibilidade de comparar o esforo planeado com o efetivamente
realizado.
Possibilidade de atribuir atividades a recursos e analisar a alocao
de cada um dos recursos.
Possibilidade do responsvel pela execuo de uma atividade introduzir informao sobre o trabalho que foi efetuado.
Possibilidade de utilizar dados histricos para elaborar estimativas
para um novo projeto.
Possibilidade de analisar no apenas as questes de prazos, mas
tambm as financeiras.
Se considerarmos a definio abrangente do conceito de ferramenta CASE,
a lista de funcionalidades seria exageradamente grande, o que esta fora do mbito deste tema. Por isso, vamos apresentar uma lista de funcionalidade dividida em grandes grupos funcionais, de forma a facilitar a compreenso.
Critrios de modelagem
Suporte a um ou mais mtodos ou paradigmas
metodolgicos.
Ferramenta orientada para a aplicao de tcnicas de modelagem ou de uma metodologia completa. Neste caso, interessa determinar a eventual capacidade de customizao
da mesma.
Tipos de modelagem suportados: modelagem de dados,
diagramas funcionais, modelao em UML, modelagem
do negcio, modelagem de instalao/distribuio de
componentes.
Nvel de cobertura s vrias tarefas do processo de
desenvolvimento.
Separao e integrao entre modelagem de nvel conceitual (conceitos do negcio e de anlise) e de implementao
(desenho e programao).
Integrao de diversos modelos e capacidade de definir
submodelos, possibilitando a existncia de diversos nveis
de abstrao.
164
captulo 5
165
166
captulo 5
ATIVIDADES
01. Faa uma pesquisa na Internet e verifique quais so as ferramentas CASE mais comentadas e suas principais caractersticas.
02. Pesquise e liste pelo menos 5 vantagens de usar ferramentas CASE.
03. Cite e explique as 4 fases do processo unificado.
04. possvel comparar o RUP com algum dos modelos de ciclo de vida apresentados no
captulo 4? Qual? Por qu?
05. Um dos principais pilares do RUP o conceito de best practices (melhores prticas),
que so regras/prticas que visam reduzir o risco (existente em qualquer projeto de softwa-
captulo 5
167
re) e tornar o desenvolvimento mais eficiente. No RUP, a passagem pelas fases chamada
de ciclo de desenvolvimento, que gera um software, adicionalmente dividido em interaes
e finalizado com ponto de avaliao para analisar os objetivos e os resultados propostos.
A iterao, com nove componentes, estruturada em workflows de processo ou fluxos de
trabalho realizados pela equipe de projeto. Ao descrever a estrutura dinmica da empresa,
objetivando o entendimento comum entre os envolvidos, sobre quais processos de negcios
devem ser contemplados, a equipe de projeto encontra-se no componente de:
a) anlise e projeto.
b) implementao.
c) modelagem de negcio.
d) requisitos.
e) teste.
REFLEXO
Em qualquer rea na qual exista uma atividade de gesto ser necessrio ter ferramentas
para auxiliar o gestor. As ferramentas CASE possuem uma abrangncia muito grande e so
excelentes para o profissional de TI acompanhar o processo de software sob sua responsabilidade.
Por meio de relatrios que elas geram, o gestor consegue medir, avaliar e prever projetos
futuros baseados em dados reais de sua equipe, e isso muito importante e sinal de maturidade da equipe e do processo. E maturidade de processo algo que o gestor espera, certo?
Aliar ferramentas e processo outro objetivo dos profissionais de TI. Como foi visto com
o processo RUP, isso possvel e vivel. O RUP um mtodo usado por vrias empresas e
de vrios portes e merece uma ateno especial em estudos futuros. Alm disso, assim como
o PMP, certificao concedida pelo PMI para gerentes de projeto, o RUP tambm possui
certificaes e pode ser um diferencial de carreira para os estudantes e profissionais que
desejam se destacar no mercado.
LEITURA
Artigo: melhorando o desempenho dos projetos com processos comprovados e adaptveis. Disponvel em: http://migre.me/oJzYU
Excelente artigo que trata sobre o RUP e processos de software.
168
captulo 5
Livro: Introduo ao RUP Rational Unified Process. Philippe Kruchten. So Paulo: Cincia Moderna, 2003. Este livro traz mais explicaes sobre os conceitos apresentados neste
captulo.
Livro: Utilizando UML e Padres. Craing Larman. Porto Alegre: Bookman, 2007. Este livro interessante, porque apresenta vrios elementos do RUP aplicado a padres de projeto.
REFERNCIAS BIBLIOGRFICAS
CANZ, A. S.; Processo Unificado (PU) - Unified Process. Disponvel em: <http://www.adonai.eti.
br/wordpress/2011/06/processo-unificado-pu-unified-process/>. Acesso em: 18 dez. 2014.
WAZLAWICK, R. S. Engenharia de Software: Conceitos e Prticas, 1. ed., Elsevier, 2013. 506p.
MACHADO, I. M. R.; PEREIRA, L. M.; Processo de Desenvolvimento de Software Livre: Um
Estudo de Caso do Projeto EAD Livre. Simpsio Mineiro de Sistemas, 2006. Disponvel em: <http://
homepages.dcc.ufmg.br/~ivre/Artigo1.pdf>. Acesso em: 17 dez. 2014.
PRESSMAN, R. S. Engenharia de Software, 7 edio. So Paulo: McGraw-Hill, 2011. p. 780.
INFOXZONE. Prxis - Engenharia de Software. 2010. Disponvel em: <http://infoxzone.wordpress.
com/2010/02/10/praxis-engenharia-de-software/>. Acesso em: 15 dez. 2014
MARTINS, V.; Processo Unificado. Disponvel em: <http://www.batebyte.pr.gov.br/modules/
conteudo/conteudo.php?conteudo=1227>. Acesso em 15 dez. 2014.
SOMMERVILLE, I. Engenharia de Software, 6. ed. Editora Pearson do Brasil, 2003. p. 292.
SOMMERVILLE, I. Engenharia de Software, 7. ed. Editora Pearson do Brasil, 2007.
GABARITO
Captulo1
01. Para o desenvolvimento de produtos de software de qualidade, sim necessrio o uso
de processos de desenvolvimento de software, uma vez que a qualidade est diretamente
ligada aos processos adotados e sua prtica adequada, desde que o resultado final atinja
as necessidades e expectativas do cliente. Caso no fosse adotado, as atividades seriam
um caos e muitos fatores de risco estariam presentes no processo de desenvolvimento, no
garantindo a qualidade nem a repetibilidade e controle. Sem processos estabelecidos, a possibilidade de gesto fica reduzida.
02. As organizaes possuem problemas por uma falta de gesto de processos, que so
captulo 5
169
170
captulo 5
Captulo2
01. Uma documentao gil quando possui estas caractersticas: Documentos geis maximizam o retorno dos clientes; so magros e econmicos; satisfazem a um propsito; descrevem informaes que tm menor probabilidade de mudar; descrevem coisas boas de se
saber; tm um cliente especfico e facilitam o trabalho desse cliente; so suficientemente
precisos, consistentes e detalhados; so suficientemente indexados.
02. Durante o processo de desenvolvimento de software pode-se documentar praticamente
tudo que necessitar ao longo de todas as etapas do processo, desde anotaes, diagramas,
fluxogramas, modelagem UML, especificaes, levantamentos de requisitos, documentos,
guias, manuais, cdigo-fonte e outros artefatos relacionados.
03. Para uma manuteno de qualidade e com a eficincia esperada praticamente impossvel efetuar sem acesso ou consulta documentao do software. No entanto, dependendo
da complexidade, e se esta for pequena, j conhecida pelos envolvidos, talvez seja sim possvel efetuar manutenes pontuais. Neste caso, estamos contando com a experincia das
pessoas, mas para o processo formal de manuteno isto no pode ser considerado.
captulo 5
171
04. No. Aps a entrega do software ao cliente, este entra na fase de manuteno e pode
sofrer reparos e ajustes, bem como melhorias e evoluir ao longo do tempo, estendendo ainda
mais o seu ciclo de vida. Talvez, o que se termine neste momento a fase de codificao, em
prol da concluso de um projeto de software, no entanto o desenvolvimento de um software
continuado com a manuteno.
05. possvel efetuar atividades de suporte e manuteno em partes do software que tenham sido concludas e que estejam devidamente entregues ao cliente, se este software
possuir uma caracterstica modular. Desta forma, espera-se que uma parte no interfira diretamente em outra parte que, eventualmente, esteja ainda em construo. Portanto, se a
entrega final contemplar o uso total do sistema, e se no for possvel ter um funcionamento
modular, dificilmente ser possvel efetuar atividades de suporte e manuteno.
06. O ciclo de melhoria contnua de um software pode ser utilizado enquanto este estiver
sendo til para o negcio. No h uma data ou uma contagem especfica, e quanto mais for
adaptado e melhorado, maior ser o seu ciclo de vida, devido s melhorias ali realizadas.
Captulo3
01. Os impactos seriam positivos, pois a adoo de uma norma em uma empresa traz maturidade e definio dos processos, direcionando-a em um caminho visando qualidade. Isto
tambm pode ter um outro lado, pois como vrios processos sero revistos ou at mesmo
exigidos, isto tambm pode provocar uma grande movimentao dentro da organizao, causando resistncias em muitas pessoas que ali trabalham, bem como sofrer grandes impactos
em relao a eventuais novos processos ou readequao dos mesmos.
02. Os nveis do CMMI podem ser assim relacionados:
Inicial. O processo caracterizado como sendo imprevisvel e ocasionalmente catico.
Poucos processos so definidos e o sucesso depende de esforos individuais e, muitas vezes, heroicos.
Repetvel. Processos bsicos de gerenciamento de projeto so estabelecidos para controle de custos, prazos e escopo. A disciplina de processo permite repetir sucessos de projetos anteriores em aplicaes similares.
Definido. Um processo composto por atividades de gerenciamento e engenharia documentado, padronizado e integrado em um processo-padro da organizao. Todos os projetos utilizam uma verso aprovada e adaptada do processo organizacional para desenvolvimento e manuteno de produtos e servios tecnolgicos.
Gerenciado. Mtricas detalhadas dos processos e dos projetos so coletadas. Tanto os
processos como os projetos so quantitativamente compreendidos e controlados.
172
captulo 5
captulo 5
173
Nvel 5
Gesto de alterao de projeto
Gesto de alterao de tecnologia
Preveno de defeitos
Captulo4
01. Os ciclos de vida de software, tambm chamados de processos de software, so um
conjunto de atividades que levam produo de um produto de software e seus artefatos. Os
ciclos de vida descrevem abstratamente a forma como os softwares podem ser desenvolvidos de acordo com o contexto no qual esto inseridos.
02. O manifesto gil composto por 12 princpios:
Nossa maior prioridade satisfazer o cliente atravs da entrega rpida e contnua de software com valor.
Mudanas nos requisitos so bem-vindas, mesmo nas etapas finais do projeto. Processos
geis usam a mudana como um diferencial competitivo para o cliente.
Entregar software frequentemente, com intervalos que variam de duas semanas a dois meses, preferindo o intervalo mais curto.
Administradores (business people) e desenvolvedores devem trabalhar juntos diariamente
durante o desenvolvimento do projeto.
Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte e
confie que eles faro o trabalho.
O meio mais eficiente e efetivo de tratar a comunicao entre/para a equipe de desenvolvimento a conversa cara a cara.
Software funcionando medida primordial de progresso.
Processos geis promovem desenvolvimento sustentado. Os financiadores, usurios e desenvolvedores devem ser capazes de manter o ritmo indefinidamente.
Ateno contnua excelncia tcnica e bom design melhoram a agilidade.
Simplicidade a arte de maximizar a quantidade de um trabalho no feito essencial.
As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.
Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva e ento ajusta seu
comportamento de acordo com essa meta.
O modelo cascata assume que os requisitos so inalterados ao longo do desenvolvimento; isto, em boa parte dos casos, no verdade, uma vez que nem todos os requisitos so
completamente definidos na etapa de anlise. Um dos riscos desta abordagem em caso de
ausncia de um processo de gesto do projeto e de controle das alteraes bem definido,
174
captulo 5
podendo passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja
disponibilizar o sistema a funcionar, devido Dificuldade em responder a mudanas dos
requisitos.
03. Letra e
04. Letra e
Captulo5
01. Alguns exemplos de ferramentas que podero ser citadas so:
System Architect
Rational Rose
Oracle Designer
GDPro
Power Designer
Silverrun
ERWin
Genexus
02. Algumas das principais vantagens das ferramentas CASE:
Uniformizao do processo de desenvolvimento, das atividades realizadas e dos artefatos
produzidos.
Reutilizao de vrios artefatos ao longo do mesmo projeto, e entre projetos, promovendo o consequente aumento da produtividade.
Automatizao de atividades, com particular destaque ao nvel da gerao de cdigo e
de documentao.
Diminuio do tempo de desenvolvimento, recorrendo gerao automtica de diversos
artefatos do projeto, ou reutilizao de outros previamente existentes.
Integrao de artefatos produzidos em diferentes fases do ciclo de desenvolvimento de
software, em que as sadas de uma ferramenta so utilizadas como entrada de outra.
Demonstrao da consistncia entre os diversos modelos e possibilidade de verificar a
correo do software.
Qualidade do produto final superior, pois a utlizao de ferramentas impe um rigor que
obriga a uma abordagem mais estruturada no processo de desenvolvimento.
03. As fases do Processo Unificado podem ser divididas em:
Concepo (Inception) entendimento da necessidade e viso do projeto,
Elaborao (Elaboration) especificao e abordagem dos pontos de maior risco,
Construo (Construction) desenvolvimento principal do sistema,
captulo 5
175
176
captulo 5