Processo de Engenharia de

Software
Prof. Raul Sidnei Wazlawick
UFSC-CTC-INE UFSC-CTC-INE
2010
Processo
O desenvolvimento de software deve ser
encarado como um processo.
Mas o que um processo?
Segundo Sommerville (2003), um processo Segundo Sommerville (2003), um processo
um conjunto de atividades e resultados
associados que produzem um produto de
software.
Mas esta definio ainda muito simples, pois
processos usualmente no so apenas
conjuntos de atividades, mas atividades
estruturadas. estruturadas.
Alm disso, h mais coisas do que apenas
atividades e resultados.
H pessoas, recursos, restries, padres a
serem seguidos, etc.
Processo (Wikipedia)
Um processo de Engenharia de Software
formado por um conjunto de passos de
processo parcialmente ordenados,
relacionados com artefatos, pessoas, recursos, relacionados com artefatos, pessoas, recursos,
estruturas organizacionais e restries, tendo
como objetivo produzir e manter os produtos
de software finais requeridos.
Um processo, ento, pode ser entendido como um
conjunto de atividades:
Interdependentes.
Com responsveis.
Com entradas e sadas definidas.
Distino
Processo
Projeto
Modelo de Processo
Projeto
Um projeto ocorre em um tempo
determinado.
Um projeto consiste na execuo concreta de
um conjunto de atividades que visam a um conjunto de atividades que visam a
criao de um produto especfico.
Processo
Um processo um conjunto de regras que
definem como um projeto deve ser executado.
Na linguagem da orientao a objetos, o projeto
pode ento ser considerado como instncia de pode ento ser considerado como instncia de
um processo.
Um processo normalmente adotado por uma
empresa como um conjunto de regras especficas
que seus funcionrios devem seguir sempre que
trabalharem em um projeto.
Modelo de Processo
O modelo de processo um conjunto de regras
mais abstratas que especificam a forma geral de
processos.
Um modelo de processo apresenta uma filosofia,
um paradigma, uma forma geral de um paradigma, uma forma geral de
comportamento, baseada na qual processos
especficos podem ser especificados.
Quando um modelo de processo definido para
as atividades de projeto e desenvolvimento de
software normalmente ele chamado de ciclo de
vida.
Vantagens da adoo de um processo
O tempo de treinamento pode ser reduzido.
mais fcil encaixar novos indivduos na equipe do que quando
no se tem processos definidos.
Produtos podem ser mais uniformizados.
Uma equipe com processo bem definido tende a produzir produtos
mais padronizados do que uma equipe sem processo algum. mais padronizados do que uma equipe sem processo algum.
Possibilidade de capitalizar experincias.
Processos no cerceiam a criatividade.
Um bom processo, bem gerenciado, deve ter mecanismos para
melhoria embutidos.
Assim, se um desenvolvedor descobrir um meio de fazer as coisas
melhor do que descrito no processo, deve haver meios para
incorporar estas alteraes.
Componentes de um processo
Modelo de Processo
Um processo pode ser definido a partir de um
modelo de processo, que consiste em um
estilo para organizar as fases e tarefas,
conforme ser visto em uma aula posterior. conforme ser visto em uma aula posterior.
As fases so as grandes divises dos
processos.
Normalmente so seqenciais e so
poucas.
Um exemplo o processo unificado
que um modelo que prope apenas
4 grandes fases concepo,
elaborao, construo e transio.
Objetivos das fases
Cada fase tem um macro-objetivo bem estabelecido.
No caso da concepo ter uma primeira abordagem sobre o
sistema e seus requisitos.
A elaborao busca aprofundar a anlise e detalhar o projeto
do sistema.
A construo visa produzir cdigo executvel e testado. A construo visa produzir cdigo executvel e testado.
Finalmente, a transio visa a instalao e operao do
sistema no ambiente final.
possvel que existam processos que se subdividem
diretamente em tarefas.
Mas se a quantidade de tarefas for muito grande isso
no recomendvel.
Processos ou fases se subdividem ento
em tarefas.
Toda tarefa tem um objetivo principal
estabelecido e visa produzir uma estabelecido e visa produzir uma
mudana de estado visvel durante um
processo de desenvolvimento de
software.
Tarefas se subdividem em atividades, que
so passos claramente identificados e
realizveis como uma unidade lgica.
Artefatos
Um artefato pode ser um diagrama, texto,
cdigo executvel, etc., ou seja, qualquer tipo
de produto criado ao longo do processo de
desenvolvimento e software.
Os artefatos so as entradas para as tarefas e
tambm so suas sadas.
Normalmente o objetivo de uma tarefa criar
artefatos ou promover alteraes consistentes
e verificveis em artefatos.
Artefatos de Entrada e Sada
As tarefas devem ter entradas e sadas bem
definidas.
O objetivo das tarefas promover a
modificao em um ou mais artefatos de modificao em um ou mais artefatos de
entrada produzindo como sada novos
artefatos e/ou uma modificao bem definida
nos artefatos de entrada.
Entregas
Artefatos de sada ainda podem ser
subclassificados em entregas, que so
artefatos entregues ao cliente.
Templates de Artefatos
Artefatos (especialmente os de texto) podem
ser definidos por templates, isto , modelos
de documentos que do uma forma geral ao
artefato. artefato.
Responsveis e Participantes
Tarefas tambm devem ter identificados os
responsveis e participantes.
Responsveis so as pessoas que devem
realizar a tarefa e responder pela sua
concluso.
J os participantes agem apenas em resposta J os participantes agem apenas em resposta
iniciativa dos responsveis.
O ideal que o responsvel seja uma nica
pessoa (ou cargo).
Por exemplo, uma tarefa de levantamento de
requisitos ter como responsvel um analista
e como participantes os clientes e usurios.
Responsveis
Deve-se descrever preferencialmente o cargo ao
invs de nomear pessoas individualmente.
Por exemplo, uma tarefa de anlise de requisitos ter
como responsvel um ou mais analistas, mas no
necessrio nome-los.
A atribuio de pessoas a tarefas feita durante o
processo de gerncia, no necessariamente no
planejamento.
No planejamento define-se apenas o perfil ou cargo
que a atividade necessita.
Participantes
Os participantes de uma tarefa so todas as
outras pessoas que precisam participar em
alguma atividade para que a tarefa seja
concluda.
No so necessariamente responsveis, mas
precisam participar.
Por exemplo, o cliente deve participar da
tarefa de levantamento de requisitos, mas o
responsvel o analista.
Recursos
Cada tarefa tambm pode necessitar de um
conjunto de recursos alocados, no apenas
recursos humanos, que j estaro previstos
como responsveis ou participantes, mas como responsveis ou participantes, mas
recursos fsicos como horas de computador,
licenas de software, papel, passagens, etc.
Tipos de Recursos
Existem recursos humanos e recursos fsicos.
Os recursos fsicos ainda dividem-se em dois
grupos:
os que so consumveis e os que so consumveis e
os no-consumveis.
Recursos humanos so associados s tarefas
como responsveis ou participantes e no
como recursos.
Recursos Consumveis
Recursos consumveis so aqueles que so gastos
quando usados.
Por exemplo, folhas de papel, passagens, etc.
Esses recursos normalmente so alocados em
determinada quantidade. determinada quantidade.
Por exemplo, para realizar uma reunio do projeto
pode-se alocar recursos consumveis como
passagens e dirias para os participantes de outras
cidades, folhas de papel pra anotaes, biscoitos e
caf.
Nenhum recurso consumvel pode ser novamente
aproveitado em outra tarefa.
Recursos No-Consumveis
Recursos no-consumveis podem ser
alocados inmeras vezes a vrias tarefas.
Porm, normalmente no podem ser
alocados a mais de uma tarefa de cada vez.
Um exemplo de recurso no consumvel Um exemplo de recurso no consumvel
o software e o hardware.
Enquanto um computador estiver sendo
usado em uma tarefa no pode ser
simultaneamente usado em outra tarefa.
Mas depois de liberado pode novamente
ser usado.
Desgaste
Recursos no-consumveis podem sofrer desgaste e
depreciao ao longo do tempo e um dia no serem
mais aproveitveis em tarefas, como por exemplo,
computadores muito antigos.
Mas isso gerenciado pelo processo de Mas isso gerenciado pelo processo de
administrao de recursos e normalmente no
dentro de um projeto que se tenta determinar se um
recurso no consumvel j passou seu tempo de uso.
Ento, para efeito e projetos, esses recursos devem
ser considerados inesgotveis.
Detalhamento da Tarefa
Modelo de documento descritivo de
tarefa
Cabealho:
Nome do processo.
Nome da fase.
Nome da tarefa.
Responsvel (cargo). Responsvel (cargo).
Participantes.
Artefatos de entrada.
Artefatos de sada.
Recursos alocados.
Corpo:
Lista das atividades e seu detalhamento.
As atividades so os passos individuais e orgnicos de um
processo.
Toda atividade necessita de uma descrio, que deve dizer
em palavras simples e diretas o que deve ser feito para
que a atividade seja realizada. que a atividade seja realizada.
Deve-se informar como os artefatos de sada so
produzidos a partir dos artefatos de entrada.
Isso deve ser feito usando um discurso essencial, ou seja,
sem entrar em detalhes sobre tecnologias a serem
usadas.
Detalhes de tecnologia devem ficar restritos aos
procedimentos associados atividade.
Nem sempre as atividades so executadas
como uma seqncia estrita. Nestes casos
pode ser interessante apresent-las na forma
de um algoritmo, ou mesmo de um de um algoritmo, ou mesmo de um
fluxograma ou diagrama de atividades (UML).
Procedimentos
Atividades podem ser detalhadas por
procedimentos, que apresentam uma
realizao tecnolgica para o passo essencial
definido. definido.
Para cada tecnologia possvel poder haver
uma descrio de procedimento associada a
cada atividade.
O procedimento uma explicao adicional
atividade que indica como realiz-la com as
ferramentas e tecnologia disponvel.
Uma atividade deve ser descrita como um caso
de uso essencial (Wazlawick, 2004), ou seja, de uso essencial (Wazlawick, 2004), ou seja,
mencionando apenas o que deve ser feito sem
detalhar a tecnologia a ser usada.
J o procedimento equivale a um caso de uso
real, que detalha a atividade com uma tecnologia
especfica.
Pode haver mais de uma possibilidade
tecnolgica para realizar uma atividade. Por
exemplo, pode haver disponveis na empresa
duas ferramentas CASE.
Assim, uma atividade de realizar modelagem Assim, uma atividade de realizar modelagem
conceitual, por exemplo, ter uma nica
descrio independente de ferramenta.
Mas haver pelo menos dois procedimentos
associados atividade, um para cada ferramenta
CASE disponvel.
Explicaes e Regras
Atividades tambm podem ser
complementadas por explicaes e
restringidas por regras.
Regras
A realizao de um processo pode ainda ser
condicionada por regras ou restries, que podem
atingir atividades, recursos, artefatos, etc.
Por exemplo, a atividade de escrever o sumrio
executivo do projeto pode ter como restrio o fato
de que este artefato no deve ter mais do que duas
pginas.
Pode-se fazer um paralelo entre atividades e
requisitos:
As atividades correspondem aos requisitos funcionais e as
restries aos no funcionais.
Detalhamento de Atividades
A seguir um template de descrio de
tarefa
Cabealho:
Corpo
Exemplo - cabealho
Exemplo
-
corpo
Equipe de Processo
As organizaes devem ter as suas equipes ou
times de processo, constitudas por um ou
mais engenheiros de software que sero
responsveis pela manuteno, avaliao e responsveis pela manuteno, avaliao e
otimizao do processo.
O Software Engineering Institute (SEI) publicou um
documento sobre como estabelecer equipes de processo de
engenharia de software, disponvel online, que pode ser de
grande valia como referncia (Fowler & Rifkin, 1990).
Segundo este documento, a equipe de processo o ponto
focal da melhoria de processos em uma empresa. focal da melhoria de processos em uma empresa.
O tamanho do grupo deveria variar entre 1 a 3% do nmero
de profissionais da empresa ligados ao processo de
desenvolvimento de software, e ele centraliza e capitaliza o
esforo colaborativo dos mais diferentes agentes no sentido
da melhoria contnua do processo adotado na empresa.
Normas Tcnicas
A norma tcnica ISO/IEC 12207:2008 adotada
internacionalmente estabelece definies e
padres referentes a vrios processos
relacionados com a indstria de software. relacionados com a indstria de software.
A norma estabelece processos, atividades e
tarefas que devem ser aplicados durante a
aquisio, fornecimento, desenvolvimento,
operao, manuteno e descarte de software.
www.iso.org/iso/catalogue_detail.htm?csnumber=43447
IEEE 12207
Existe tambm uma norma, a IEEE 12207 que
consiste na adoo e adaptao da ISO 12207
pela IEEE.
Este documento pode ser adquirido Este documento pode ser adquirido
diretamente no site da IEEE (www.ieee.org)
por cerca de 200 dlares.
Gray (1999) apresenta um comparativo entre
as duas normas.
ABNT
A ABNT adotou a norma ISO/IEC 12207,
transformando-a tambm em padro
brasileiro, a NBR ISO/IEC 12207:2009.
A norma pode ser adquirida por R$206,40 A norma pode ser adquirida por R$206,40
(preo de agosto de 2010) no site:
www.abntcatalogo.com.br/norma.aspx?ID=38643
Famlias de processo 12207
Processos fundamentais, que so necessrios para que
um software seja construdo e executado.
Processos de apoio, que auxiliam outros processos,
garantindo qualidade, por exemplo, mas no so
fundamentais. fundamentais.
Processos organizacionais, que so usados no contexto
da organizao para permitir o melhor
acompanhamento e gerenciamento dos projetos.
Processo de adaptao, onde a norma estabelece
como ela prpria pode ser aplicada a uma organizao
ou projeto especfico.
Processos Fundamentais
Aquisio. o processo para obteno do produto ou servio de
relacionado a informtica que satisfaa as necessidades da sua
empresa.
Fornecimento. o processo cujo objetivo fornecer um produto ou
servio a terceiros.
Desenvolvimento. definido como o processo de transformar um
conjunto de requisitos em produto executvel. conjunto de requisitos em produto executvel.
Operao. Possui o objetivo de iniciar e manter o produto operando
em seu local definitivo bem como prestar servios aos usurios.
Manuteno. Tem como propsito modificar o produto, removendo
erros e adequando-o a novos contextos (ver captulo 15).
Processos de Apoio
Documentao. O processo de documentao tem como propsito criar e manter
informaes sobre o produto.
Gerncia de configurao. Tem como propsito gerenciar e manter a consistncia
entre todas as verses dos produtos do trabalho de forma a manter tambm sua
integridade.
Garantia de qualidade. Tem como propsito garantir que os produtos e servios
estejam em conformidade com normas e padres pr-definidos, bem como em
relao aos requisitos. relao aos requisitos.
Verificao. Tem como objetivo garantir ou confirmar que os produtos refletem os
requisitos especificados.
Validao. Tem como objetivo garantir ou confirmar que os requisitos
especificados so os que realmente so desejados pelo cliente.
Reviso conjunta. Tem como propsito manter um entendimento comum entre os
diversos interessados a respeito do produto, do processo ou do servio.
Auditoria. Tem como propsito prover uma avaliao independente dos produtos
e processos.
Resoluo de Problemas. Tem o propsito de assegurar que todos os problemas
levantados sejam resolvidos.
Processos Organizacionais
Gerncia. Tem como objetivo organizar e controlar a
realizao dos projetos bem como seu desempenho.
Infra-estrutura. Tem como objetivo manter um
ambiente de trabalho adequado.
Melhoria. Tem como objetivo permitir que os
processos possam continuamente ser adaptados
visando a otimizao do trabalho.
Treinamento ou recursos humanos. Tem como
objetivo manter os recursos humanos capacitados
para o melhor desempenho possvel das suas
funes.
Bibliografia
Fowler, P., Rifkin, S. (1990). Software Engineering Process Group Guide. SEI.
Disponvel em: http://www.sei.cmu.edu/reports/90tr024.pdf. Consultado
em: 01/03/2010.
Gray, L. (1999). A Comparison of IEEE/EIA 12207, ISO/IEC 12207, J-STD-016,
and MIL-STD-248 for Acquirers and Developers. Abelia Corporation.
Disponvel em: http://www.abelia.com/docs/122_016.pdf. Consultado em:
16/08/2010.
Sommerville, I. (2003). Engenharia de Software - 6
a
Edio. Ed. Addison- Sommerville, I. (2003). Engenharia de Software - 6
a
Edio. Ed. Addison-
Wesley.
Wazlawick, R. S. (2004). Anlise e Projeto de Sistemas de Informao
Orientados a Objetos. Elsevier.
Wikipdia (2010) Processos de Engenharia de Software. Disponvel em:
http://pt.wikipedia.org/wiki/Processos_de_Engenharia_de_Software.
Consultado em: 26/02/2010.
Wikipedia (2010d). ISO/IEC 12207. Disponvel em:
http://pt.wikipedia.org/wiki/ISO/IEC_12207. Consultado em 16/08/2010.