ti - conhecimentos específicos - engenharia da computação - concursos
TRANSCRIPT
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
1/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
2/420
2.1 O que Processo de Software
Um processo de software pode ser definido como um conjunto coerente de atividades,
polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios
para conceber, desenvolver, dispor e manter um produto de software (FUGGETTA, 2000).
Um processo eficaz deve, claramente, considerar as relaes entre as atividades, os
artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessrios e
a habilidade, o treinamento e a motivao do pessoal envolvido (FALBO, 1998).
A escolha de um modelo de ciclo de vida (ou modelo de processo) o ponto de
partida para a definio de um processo de desenvolvimento de software. Um modelo de
ciclo de vida organiza as macro-atividades bsicas, estabelecendo precedncia edependncia entre as mesmas (FALBO, 1998).
Processos de software definem o conjunto de atividades conduzidas no contexto do
projeto, tais como anlise de requisitos, projeto, codificao, teste, instalao etc, os
recursos (software, hardware e pessoas) necessrios e os procedimentos a serem adotados
na realizao de cada uma das atividades. Sendo que essas atividades so compostas por
outras atividades e podem se comunicar entre si e operam sobre artefatos de entrada para
produzir artefatos de sada (FALBO, 1998) (GRUHN, 2002).
Outra questo que envolve a elaborao de um processo de software a sua
adequao ao domnio de aplicao e ao projeto. A cada projeto, o processo de software
deve ser ajustado s especificidades da aplicao, tecnologia a ser utilizada na sua
construo, grupo de desenvolvimento e usurios finais (FALBO, 1998).
2.2 Nveis de Processo de Software
Apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer
conjuntos de ativos de processo (sub-processos, atividades, sub-atividades, artefatos,
recursos e procedimentos) comuns para toda a organizao. Esses conjuntos constituem os
chamados processos padro de uma organizao. A partir deles, outros processos, ainda
padro, podem ser especializados, levando-se em considerao caractersticas como tipos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
3/420
de software, paradigmas ou domnios de aplicao. Finalmente, para cada projeto, pode-se
instanciar um processo padro, especializado ou no, buscando atender s suas
caractersticas prprias, definindo os chamados processos de projeto (ROCHA et al., 2001)
(BERTOLLO et al., 2006).
Esse modelo de definio de processos em nveis adotado no Laboratrio de
Engenharia de Software (LabES) da UFES, como mostra a Figura 2.1. Os processos padro
para o desenvolvimento e manuteno de software do LabES so definidos tomando por
base modelos e normas de qualidade, principalmente as normas ISO/IEC 12207 (ISO/IEC,
1998) e IEEE 1219 (IEEE, 1998) e o modelo MPS.BR (SOFTEX, 2006).
Figura 2.1 Modelo para Definio de Processos em Nveis
A partir deles so especializados outros processos padro de desenvolvimento e
manuteno, tais como os Processos Especializados para o Desenvolvimento Orientado a
Objetos (PPELabESOO) e para o Desenvolvimento segundo o Paradigma Estruturado
(PPELabES-Est). Esses processos podem ser recursivamente especializados, criando outros
nveis na hierarquia. Por exemplo, conforme discutido no captulo 4 deste trabalho, a partir
dos processos especializados para desenvolvimento e manuteno orientados a objetos,
foram definidos processos especializados para desenvolvimento e manuteno de Software
Livre no LabES, considerando a heterogeneidade dos grupos de trabalho, caractersticas do
Processo Padro
Especializao
Normas e Modelos deQualidade,
Cultura Organizacional
Tipo de Software,Domnio do Problema,
Paradigma eTecnologia de
Desenvolvimento
Particularidades doProjeto, Modelo deCiclo de Vida (ou
Modelo de Processo)
Processo Especializado 1 Processo Especializado n
Processo de Projeto mProcesso de Projeto 1
PPLabES
Instanciao
Definio
ISO/IEC 12207,IEEE 1219, MPS.BR
PPELabES-OOPPELabES-Est
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
4/420
desenvolvimento de software com equipes geograficamente dispersas e prticas aplicadas a
projetos de Software Livre bem sucedidos.
2.3 Qualidade de Processo de Software
Quando se produz um software, assim como qualquer outro produto, desejvel que
o mesmo possua elevada qualidade, que seja produzido de forma otimizada e dentro dos
prazos estabelecidos previamente. No desenvolvimento de software, uma das principais
maneiras de se garantir tais caractersticas para o produto final atravs de um processo de
software de qualidade. Ou seja, se um produto de software foi desenvolvido seguindo um
processo de qualidade, as chances do mesmo ser um produto de qualidade so maiores.
Alm disso, para que a organizao que produz software tenha sua qualidadereconhecida em todo o mundo, seus processos devem respeitar padres de qualidade
definidos pela comunidade de software.
Desde a dcada de 1980, iniciaram-se esforos para melhoria de processos de
software, com o objetivo de melhorar a qualidade, aumentar a produtividade e diminuir os
custos. Diferentes modelos so utilizados dependendo do mercado alvo das organizaes de
software (ROCHA et al., 2001). As principais normas e modelos de qualidade difundidos
atualmente so: ISO 9000 (ISO, 2000), ISO/IEC 12207 (ISO/IEC, 2008), ISO/IEC 15504
(ISO/IEC, 2003), CMMI (SEI, 2006) e MPS.BR (SOFTEX, 2007), sucintamente
apresentados na seqncia.
2.3.1 ISO 9000:2000
As normas da famlia NBR ISO 9000:2000 (ISO, 2000) foram desenvolvidas para
apoiar organizaes de todos os tipos e tamanhos (no s as de software), na
implementao e operao de sistemas de gesto da qualidade eficazes.
A norma ISO 9000 descreve os fundamentos de sistemas de gesto da qualidade, que
constituem o objeto da famlia NBR ISO 9000, e define os termos a ela relacionados (ISO,
2000).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
5/420
A famlia NBR ISO 9000 composta de uma srie de normas, sendo a ISO 9001 a
mais completa, abrangendo todo o ciclo de vida de um produto ou servio, cobrindo os
requisitos para a garantia da qualidade em projetos, desenvolvimento, produo, instalao
e servios associados (MUTAFELIJA et al., 2003).
A ISO 9000:2000 baseada em um conjunto de princpios de gerenciamento de
qualidade, definidos a partir da experincia de vrias organizaes (ISO, 2000):
Princpio 1 - Foco no cliente: Dado que as organizaes dependem de seus
clientes, recomendvel que atendam s suas necessidade atuais e futuras e
aos seus requisitos e procurem exceder as suas expectativas.
Princpio 2 -Liderana: Lderes estabelecem a unidade de propsito e o rumo
da organizao. Convm que criem e mantenham um ambiente onde as
pessoas estejam totalmente envolvidas no propsito de atingir os objetivos da
organizao.
Princpio 3 - Envolvimento de pessoas: Pessoas de todos os nveis so a
essncia de uma organizao. Seu envolvimento possibilita o aproveitamento
de suas habilidades por toda a organizao.
Princpio 4 - Abordagem de processo: Um resultado desejado alcanado
mais eficientemente quando suas atividades e recursos so gerenciados comoum processo.
Princpio 5 - Abordagem sistmica para a gesto: Identificar, entender e
gerenciar os processos inter-relacionados como um sistema contribui para a
eficcia e eficincia da organizao no sentido desta atingir os seus objetivos.
Princpio 6 - Melhoria contnua: Convm que a melhoria contnua do
desempenho global da organizao seja seu objetivo permanente.
Princpio 7 - Abordagem factual para tomada de deciso: Decises eficazes
so baseadas na anlise de dados e informaes.
Princpio 8 - Benefcios mtuos nas relaes com os fornecedores: Pelo fato
de organizao e fornecedores serem interdependentes, uma relao de
benefcios mtuos aumenta a capacidade de ambos em agregar valor.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
6/420
Para que as organizaes funcionem de forma eficaz, elas tm que identificar e
gerenciar processos inter-relacionados e interativos. Freqentemente, a sada de um
processo resultar diretamente na entrada do processo seguinte. A identificao sistemtica
e a gesto dos processos empregados na organizao e, particularmente, as interaes entre
tais processos so conhecidos como abordagem de processos. Assim, a inteno desta
norma encorajar a adoo da abordagem de processo para a gerncia da qualidade em
uma organizao (ISO, 2000).
2.3.2 ISO/IEC 12207
Ver na Norma ISO/IEC 12207:2008 as seguintes sees:
Seo 1 (pgs 1 e 2)
Seo 5 (pgs 9 a 18)
2.3.3 ISO/IEC 15504
A norma internacional ISO/IEC 15504 (ISO/IEC, 2003) estabelece uma estrutura paraa avaliao de processos. Essa estrutura pode ser usada por organizaes envolvidas com
planejamento, gerenciamento, monitorao, controle e melhoria de aquisio,
fornecimento, desenvolvimento, operao, evoluo e suporte de software. So propsitos
dessa norma:
ajudar organizaes a compreender o estado de seus prprios processos com
vistas melhoria;
ajudar organizaes a determinar a adequao de seus processos para umrequisito particular ou classe de requisitos;
ajudar organizaes a determinar a adequao de processos de uma outra
organizao para um contrato particular ou classe de contratos.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
7/420
A norma consiste das seguintes partes, sob o ttulo geral Tecnologia de Informao
Avaliao de Processo de Software (ISO/IEC, 2003):
Parte 1: Conceitos e vocabulrio (informativo): prov uma introduo geral
aos conceitos de avaliao de processos e um glossrio de termos relacionadosa avaliao.
Parte 2: Realizando uma avaliao (normativa): define os requisitos mnimos
para a realizao de uma avaliao.
Um modelo de referncia para processos e capacidade de processos
Parte 3: Guia para a realizao de avaliaes (informativa): prov orientaes
para interpretar os requisitos para a realizao de uma avaliao.
Parte 4: Guia para uso na melhoria de processo e na determinao da
capacidade de processo (informativa): identifica a avaliao de processo como
uma atividade que pode ser realizada tanto como parte de uma iniciativa de
melhoria de processo quanto parte de uma abordagem de determinao da
capacidade.
Parte 5: Um Exemplo de modelo de avaliao de processo baseado na
ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): contm um exemplo de
modelo de avaliao de processo que baseado no modelo de processo de
referncia definido na ISO/IEC 12207.
A parte 5 da norma ISO/IEC 15504 desperta maior interesse para os interessados na
definio de processo, por oferecer um modelo de referncia disposto a guiar a definio de
um processo de software de qualidade. De fato, o objetivo dessa parte da ISO/IEC 15504
definir um exemplo de um Modelo de Avaliao de Processo que satisfaz os requisitos da
ISO/IEC 15504-2 e que apia a realizao de uma avaliao, provendo indicadores para
guiar a interpretao dos propsitos de processo, conforme definidos na ISO/IEC 12207, e
dos atributos de processo definidos ISO/IEC 15504-2.
O Modelo de Avaliao de Processo nesta parte da ISO/IEC 15504 dirigido a
patrocinadores de avaliaes e avaliadores competentes que desejem escolher um modelo
para avaliao, seja para determinao da capacidade seja para melhoria de processo.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
8/420
Adicionalmente, esse modelo pode ser til para os desenvolvedores de modelos de
avaliao, provendo exemplos de boas prticas de gerncia e engenharia de software.
2.3.4 CMMI
O projeto CMMI (Capability Maturity Model Integration) (SEI, 2006) foi
concebido para solucionar o problema do uso de mltiplos modelos de maturidade de
capacitao, tendo como foco trs modelos principais: SW-CMM (Capability Maturity
Model for Software), SECM (System Engineering Capability Model) e IPD-CMM
( Integrated Product Development Capability Maturity Model) (CHRISSIS et al., 2003).
um projeto patrocinado pelo Departamento de Defesa Americano, em conjunto com a
indstria, por meio do Comit de Engenharia de Sistemas na Associao Industrial de
Defesa Nacional, e o Instituto de Engenharia de Software (Software Engineering Institute
SEI). O projeto CMMI envolveu um grande nmero de pessoas de diferentes organizaes
de todo o mundo, interessadas nos benefcios do desenvolvimento de uma estrutura
integrada em prol da melhoria de processos.
Apesar de prover um novo modelo, o CMMI procura preservar ao mximo os
investimentos feitos em melhoria de processos baseadas no SW-CMM.
O objetivo do CMMI fornecer direcionamentos para melhorar os processos deuma organizao e sua capacidade de gerenciar o desenvolvimento, aquisio e manuteno
de produtos e servios. O CMMI prov abordagens comprovadas em uma estrutura que
ajuda organizaes a avaliar sua maturidade ou capacidade em determinada rea de
processo, estabelecer prioridades para melhoria e implementar essas melhorias.
bom lembrar que o CMMI direcionado para a melhoria de processos de
organizaes de qualquer tipo. Alm disso, como outros modelos de maturidade de
capacitao, os modelos do CMMI fornecem orientaes a serem utilizadas no
desenvolvimento de processos. Ou seja, esses modelos no so processos ou descries de
processos. Os processos reais utilizados em uma organizao dependem de vrios fatores,
incluindo domnio de aplicao e tamanho e estrutura da organizao. Assim, normalmente,
as reas de processo do modelo CMMI no podem ser mapeadas uma a uma em processos
utilizados em uma organizao (SEI, 2006).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
9/420
O CMMI tem duas representaes: em estgio e contnua. Ambas as representaes
contm reas de processo comuns. Porm, na representao em estgio, as reas de
processo esto agrupadas em nveis de maturidade e na representao contnua, a mesma
rea de processo est dividida em categorias.
A representao contnua permite selecionar a seqncia de melhorias que melhor
atende aos objetivos de negcio e reduz as reas de risco da organizao. Tambm permite
comparaes entre organizaes em uma rea de processo pela comparao de resultados
utilizando estgios equivalentes (SEI, 2006).
A representao em estgios oferece uma seqncia comprovada de melhorias,
comeando com prticas bsicas de gerncia e progredindo por um caminho pr-definido e
comprovado de nveis sucessivos, cada um servindo de base para o prximo. Alm disso,
permite comparaes entre organizaes pelo uso de nveis de maturidade (SEI, 2006).Mesmo no sendo objetivo principal da representao contnua a classificao em
um determinado nvel de maturidade, e sim o desenvolvimento de determinadas reas de
processos, um determinado nvel de maturidade pode ser atingido por quem usa a
representao contnua, se todas as reas de processo relevantes para tal nvel tiverem
atingido a capacidade mnima para o nvel de maturidade.
Os componentes do Modelo CMMI incluem nveis de maturidade (Maturity Levels),
reas de processo ( Process Areas - PAs), metas genricas (Generic Goals - GG), metas
especficas (Specific Goals - SG), prticas genricas (Generic Practices - GP) e prticas
especficas (Specific Practices - SP), como ilustra a Figura 2.4.
Uma rea de processo um grupo de prticas relacionadas em uma rea que,
quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas
importantes para trazer uma melhoria significativa naquela rea. As reas de processos do
CMMI so as mesmas para ambas as representaes (contnua e em estgios). Na
representao em estgios, as reas de processo esto organizadas por nveis de maturidade.
As metas especficas se aplicam a uma rea de processo e contemplam
caractersticas nicas que descrevem o que deve ser implementado para satisfazer tal rea.
Metas especficas so componentes exigidos do modelo e so utilizadas nas avaliaes para
auxiliar a determinar se a rea de processo est sendo satisfeita.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
10/420
Prticas especficas so atividades consideradas importantes na satisfao de suas
metas especficas associadas. Descrevem atividades focadas no atendimento de metas
especficas de uma rea de processo. As prticas especficas so componentes esperados do
modelo.
As metas genricas so chamadas de genricas, pois a mesma declarao de meta
encontrada em diversas reas de processos. Na representao em estgios, cada rea de
processo tem somente uma meta genrica. A satisfao de uma meta genrica em uma rea
de processo significa um controle melhorado do planejamento e implementao dos
processos associados com aquela rea de processo, indicando, portanto, se esses processos
parecem ser eficientes, repetveis e durveis. As metas genricas so componentes exigidos
do modelo e so utilizadas em avaliaes para determinar a satisfao de uma rea de
processo.As prticas genricas oferecem uma institucionalizao que garante que os
processos associados com a rea de processo em questo sero eficientes, repetveis e
durveis. As prticas genricas so categorizadas pelas metas genricas e caractersticas
comuns e so componentes esperados em modelos CMMI.
to Perform
Maturity Levels
Generic Practices
Generic Goals
Process Area 2
Caractersticas Comuns
Process Area 1 Process Area n
Ability
Implementation
Verifying
to Perform
Commitment Directing
Implementation
Specific Goals
Implementation
Specific Practices
Nveis de Maturidade
Prticas Genricas
Metas Genricas
rea de Processo 2rea de Processo 1 rea de Processo n
Habilitao ImplementationVerificao daCompromissoImplementao
Metas Especficas
Implementao
Prticas Especficas
Figura 2.4 Componentes do Modelo CMMI.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
11/420
O nvel de maturidade de uma organizao uma maneira de prever o futuro
desempenho da mesma dentro de dada disciplina ou conjunto delas. A experincia mostra
que as organizaes funcionam melhor quando concentram seus esforos de melhoria de
processos em um nmero controlado de reas de processos que exigem esforo cada vez
mais sofisticado medida que a organizao melhora.
Cada nvel de maturidade, alm de representar uma etapa evolucionria definida da
melhoria de processos, estabiliza uma parte importante dos processos da organizao.
Nos modelos CMMI com representao em estgios, existem cinco nveis de
maturidade, cada um representando uma camada da base da melhoria de processos,
definidos pelos nmeros de 1 a 5. A Tabela 2.1 apresenta as reas de processo do CMMI
para Desenvolvimento, organizados em nveis de maturidade.
Tabela 2.1 Nveis de Maturidade e reas de Processos do CMMI-Dev.
Nvel rea de Processo
Inovao Organizacional5 (mais alto)
Anlise de Causas e Resoluo de ProblemasDesempenho do Processo Organizacional
4Gerncia Quantitativa de ProjetoAnlise de DecisoGerncia de Riscos
Gerncia Integrada de ProjetoTreinamento OrganizacionalDefinio do Processo OrganizacionalFoco no Processo OrganizacionalValidaoVerificaoIntegrao de ProdutoSoluo Tcnica
3
Desenvolvimento de RequisitosMedio e Anlise
Gerncia de ConfiguraoGarantia da Qualidade de Processo e ProdutoGerncia de Acordo com FornecedoresMonitoramento e Controle de ProjetoPlanejamento de Projeto
2
Gerncia de Requisitos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
12/420
2.3.5 MPS.BR
Ver no Guia Geral do MPS.BR as seguintes sees:
Seo 2 (pgs 5 e 6) Seo 3 (pg 7)
Seo 6 (pgs 12 e 13)
Seo 7 (pgs 14 e 15)
Seo 8 (pgs 15, 16 (apenas dois primeiros pargrafos) e 21).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
13/420
Gerenciamento de Projetosna Engenharia de Software
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
14/420
1. Introduo
Ao analisarmos as diferentes referncias relativas a gerenciamento de projetos
de software, verificamos que h diferentes vises sobre como estes projetos devem ser
gerenciados e estas so centradas em alguns modelos. Assim no basta apenas avaliarmos asvises de diferentes autores sobre o assunto, mas tambm os diferentes modelos propostos
pelas principais instituies que propem modelos na rea, o PMI Project Management
Institute, o SEI Software Engineering Institute e ISO International Standards
Organization, alm de um modelo comercial amplamente difundido, o RUP IBM Rational
Unified Process.
Ao nos determos sobre os diferentes modelos, verificamos que o
gerenciamento de projetos constitui-se em uma tarefa de fundamental importncia no
processo de desenvolvimento de software. O gerenciamento de projeto, no entanto, no
visto como uma etapa clssica do processo de desenvolvimento, uma vez que ele acompanha
a todas as etapas tradicionais: Concepo, Anlise, Projeto, Desenvolvimento, Testes e
Manuteno.
Segundo a ABNT, na norma tcnica NBR 10006, Projeto Processo nico,
consistindo de um grupo de atividades coordenadas e controladas com datas para incio e
trmino, empreendido para alcance de um objetivo conforme requisitos especficos, incluindo
limitaes de tempo, custo e recursos. De acordo com o Project Management Institute
(PMBOK, 2004), Projeto Um empreendimento temporrio, planejado, executado e
controlado, com objetivo de criar um produto ou servio nico.
Segundo Pressman (1995), para que um projeto de software seja bem sucedido,
necessrio que alguns parmetros sejam corretamente analisados, como por exemplo, o
escopo do software, os riscos envolvidos, os recursos necessrios, as tarefas a serem
realizadas, os indicadores a serem acompanhados, os esforos e custos aplicados e a
sistemtica a ser seguida. A anlise de todos estes parmetros seria a funo tpica do
gerenciamento de projetos a qual, em geral, se inicia antes do trabalho tcnico e prossegue
medida que a entrega do software vai se concretizando.
De acordo com Capers Jones (apudChang & Christensen, 1999) a maioria
dos esforos em engenharia de software tem se preocupado em construir ferramentas CASE
para auxiliar no projeto, implementao e teste, enquanto os mtodos formais e ferramentas
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
15/420
usadas para medir, planejar, estimar e monitorar os projetos de software so praticamente
inexistentes.
Para entender e avaliar melhor a origem as falhas em projetos foram realizados
muitos estudos e pesquisas dentre eles o DOD (Departamento de Defesa do Estados Unidos,1994) e os do Standish Group (2001).
O estudo conduzido pelo DOD na dcada de 90 indicou que 75% de todos os
grandes sistemas intensivos de software adaptados falham e que a causa principal o pobre
gerenciamento por parte do desenvolvedor e adquirente e no o desempenho tcnico. O
conjunto de estudos desenvolvidos pelo Standish Group chamado de relatrio CHAOS
(Standish Group, 2001) tem como foco a indstria de software comercial. Nesta pesquisa
foram analisados cerca de 40.000 projetos de aplicaes de Tecnologia da Informao emgrandes empresas norte-americanas.
O primeiro cenrio mostra uma realidade de 1994, onde foram observadas as
seguintes concluses: As empresas dos Estados Unidos gastaram $81 milhes em projetos de
software que foram cancelados em 1994; 31% dos projetos de software estudados foram
cancelados antes de estarem concludos; 53% dos projetos de software excedem mais do que
50% a sua estimativa de custo; e, somente 9% dos projetos, em grandes empresas, foram
entregues no tempo e oramento; para empresas de pequeno e mdio porte, os nmerosmelhoraram em 28% e 16% respectivamente.
O segundo cenrio, resultante do relatrio CHAOS de 2001, mostra a
evoluo do quadro anteriormente mencionado, conforme as concluses abaixo: O percentual
de projetos entregues dentro do tempo, custo e especificaes previstos subiu para 28%; a
percentual de projetos cancelados ou falidos antes de serem completados caiu para 23%; a
extrapolao de oramento caiu para 45% e a de prazo caiu para 63%;
Segundo o Standish Group, as principais causas de falhas nos projetos esto
associadas a dificuldades com os seguintes temas: apoio da alta gerncia, envolvimento do
usurio, experincia do gerente do projeto e definio clara das regras do negcio e escopo do
projeto.
Outra pesquisa, realizada na Universidade Estadual da Pennsylvania EUA
(2000) indica que, de uma maneira geral, os motivos mais relevantes nas falhas dos projetos
de software esto relacionados a problemas na comunicao da equipe do projeto entre si e
desta com a sua gerncia e demais envolvidos..
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
16/420
De um modo geral essas anlises levaram as mesmas concluses que so:
A imprevisibilidade do desenvolvimento de software;
Baixo percentual de projetos de software so entregues com sucesso dentro das
estimativas de oramento e custo; O sucesso ou falha dos projetos determinado em grande parte pelo gerenciamento
dos projetos;
Processos imaturos resultam em retrabalho.
Estas pesquisas apontam um relacionamento direto entre a utilizao de
tcnicas de gerenciamento de projetos e o progresso observado nas estatsticas apresentadas.
Fica evidente ento que as prticas de gerenciamento de projetos devem acompanhar a
evoluo das demais prticas gerenciais para que se tenha sucesso nos projetos de tecnologia
da informao.
Braga (1996) afirma que no se pode gerenciar o que no se pode medir.
importante estar ciente que as medidas so uma forma para se estimar prazos, custos e avaliar
a produtividade do desenvolvimento de software. Desta forma, torna-se importante integrar a
mtrica de software ao planejamento/gerenciamento de projetos, como forma de viabilizar
informaes consistentes para a tomada de deciso pertinente ao gerenciamento de projeto.
O contexto do gerenciamento de projetos moderno
O gerenciamento de projetos moderno, deve sua primeira grande contribuio
ao engenheiro Henry Laurence Gantt, com o Grfico de Gantt, em 1917. Seu grande
incremento, entretanto, ocorrreu durante a guerra fria, no final dos anos 50. A corrida do
governo americano para desenvolvimento tecnolgico detonada pela crise do Sputnik em
1957, resultou em vrias reaes. Algumas delas foram: a criao da NASA em 1958, oaumento drstico do oramento da Fundao Nacional de Cincias americana, de 34 para 134
milhes de dlares em 1959, e a criao do Programa de Msseis Polaris, com a construo de
um submarino nuclear para diminuir a diferena em relao ao arsenal russo. O Departamento
de Defesa Americano (DOD) tinha urgncia para realizar o programa e as ferramentas de
gerenciamento de projetos tradicionais no eram suficientes para garantir a entrega do projeto.
O DOD ento desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation and
Review Technique), um sistema de sequenciamento de atividades que consegue determinar omenor tempo para a concluso de um projeto. A utilizao do PERT se tornou obrigatrio
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
17/420
para todos os projetos da marinha Americana. A Agncia de Pesquisa Avanada de Projetos
de Defesa do Pentgono iniciou nos anos 60 o projeto de uma rede de computadores chamada
ARPANET, que foi a percussora da Internet de hoje. Nesta mesma poca outros avanos
foram desenvolvidos no gerenciamento de projetos. A DuPont criou o CPM (Critical Path
Method), ou Mtodo do Caminho Crtico, que amplamente usado atualmente, para
identificar quais so as atividades crticas de um projeto que podem atras-lo. O trabalho do
PERT foi depois estendido para a Estrutura Analtica do Projeto (EAP). A fundao do PMI
(Project Management Institute) em 1969 sintomtica da evoluo e da formalizao do tema
nesse perodo. Porm, somente a partir dos 80 a indstria de software passou a incluir o
gerenciamento de projetos formal em suas prticas.
A seguir sero apresentadas as vises de gerenciamento de projetosapresentadas no Corpo de Conhecimento de Gerncia de Projetos (PMBOK , 2004) que a
bblia da profisso de gerncia de projetos, alm das prticas de gerenciamento de projetos
dentro dos modelos RUP Rational Unified Process (Rational Unified Process, 1998), SW-
CMM (Paulk 1993 e SEI-CMMI, 2000) e da Norma ISO/IEC 12207. Este trabalho se prope
a ser uma continuao dos trabalhos de Machado e Burnett (2003), acrescendo principalmente
a viso RUP.
2. PMBOK Guia para o Corpo de Conhecimento em Gerenciamento de
Projetos
Em 1987, o PMI publicou o primeiro conjunto de padres em Gerenciamento
de Projetos, chamado The Project Management Body of Knowledge (PMBOK Guide). Este
guia foi atualizado em 1996 e 2000 e novo PMBOK Terceira Edio foi lanado Novembro
de 2004. O PMBOK um guia onde se descreve a somatria de conhecimento e as melhoresprticas dentro da profisso de gerncia de projetos. um material genrico que serve para
todas as reas de conhecimento, ou seja, tanto para construo de edifcio, processo de
fabricao industrial, como para a produo de software.
Na definio do PMBOK (2004), gerenciamento de projetos a aplicao
de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de
atender os requisitos das partes interessadas. Para Vargas (2000) o gerenciamento de
projetos pode ser aplicado a qualquer situao onde exista um empreendimento que foge aoque fixo e rotineiro na empresa (ad hoc).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
18/420
Satisfazer ou exceder as necessidades envolve equilibrar as vrias demandas
concorrentes em relao ao:
Escopo, tempo, custo e qualidade;
Partes interessadas com necessidades e expectativas diferenciadas; e
Requisitos identificados (necessidades) e requisitos no identificados (expectativas).
Para cobrir todas as reas que fazem parte da gerncia de projetos o PMBOK
se subdividiu em processos, conforme a Figura 1.
Figura 1: Processos de Gerenciamento de projetos
Cada processo se refere a um aspecto a ser considerado dentro da gerncia de projetos e, todos
os processos devem estar presentes quando da execuo do projeto para que esse tenha
sucesso. O conjunto de conhecimentos tcnicos de Gerenciamento de projetos necessrios
para o perfeito desempenho da funo percorre nove reas do conhecimento, descritas na
figura 2.
Figura 2: reas de Conhecimento do Gerenciamento de projetos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
19/420
Estes conhecimentos so aplicados ao longo dos processos de Gerenciamento de projetos, de
forma matricial. A relao entre as nove reas de conhecimento e os cinco Processos, :
Gerenciamento
deProjetos
IniciaoPlanejamento
Execuo Controle Encerramento
Integrao DesenvolvimentodoPlanos de Projeto
Execuo doPlanos de Projeto
Gerenciamentointegrado demudanas
Gerenciamento de
Escopo
IniciaoPlanejamento dedefinio doEscopoDefinio,Sequnciamento ede Escopo
Verificao econtrole demudanas
Gerenciamento deTempo
Estimativa deAtividades
Desenvolvimentodo Cronograma
Controle deCronograma
Gerenciamento deCusto
Planejamento deRecursosEstimativa deCustos ,Oramento
ControleFinanceiro
Gerenciamento deQualidade
Planejamento daQualidade
Garantia daQualidade
Controle deQualidade
Gerenciamento deRH
PlanejamentoOrganizacionalMontagem deEquipe
Desenvolvimentode Equipe
Gerenciamento de
Comunicao
Planejamento da
Comunicao
Distribuio de
Informao
Relatrios de
Performance
Encerramento
AdministrativoGerenciamento deRiscos
Planejamento,Identificao,Qualificao,Quantificao eRespostas aosRiscos
Acompanhamentoe Controle deRiscos
Gerenciamento deContratao
Planejamento deContratosPlanejamento daContrataoSolicitao
SolicitaoSeleo deFornecedoresAdministrao deContratos
Encerramentodos Contratos
Tabela 1: Relao entre reas de Conhecimento do Gerenciamento e processos do gerenciamento de projetos
A seguir so apresentadas as reas de conhecimento descritas no PMBOK:
Gerenciamento da integrao: O objetivo principal realizar as negociaes
dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder
as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a
execuo do plano do projeto, e o controle geral de mudanas.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
20/420
Gerenciamento do Escopo: O objetivo principal definir e controlar o que
deve e o que no deve estar includo no projeto. Consiste da iniciao, planejamento,
definio, verificao e controle de mudanas do escopo.
Gerenciamento do Prazo: O objetivo principal garantir o trmino do projetono tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades, e de
elaborao e controle de prazo.
Gerenciamento do Custo: O objetivo principal garantir que o projeto seja
executado dentro dos oramento aprovado. Consiste de planejamento de recursos ,e
estimativa, oramento e controle de custos.
Gerenciamento da Qualidade do Projeto: O objetivo principal garantir que
o projeto vai satisfazer as exigncias para as quais foi contratado. Consiste de planejamento,
garantia e controle de qualidade.
Gerenciamento dos Recursos Humanos: O objetivo principal garantir o
melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento
organizacional, alocao de pessoal e desenvolvimento de equipe.
Gerenciamento da Comunicao: O objetivo principal garantir a gerao
adequada e apropriada, coleta, disseminao, armazenamento e disposio final das
informaes do projeto. Consiste do planejamento da comunicao, distribuio da
informao, relatrio de acompanhamento e encerramento administrativo.
Gerenciamento do Risco: O objetivo principal maximizar os resultados de
ocorrncias positivas e minimizar as conseqncias de ocorrncias negativas. Consiste de
identificao, quantificao, tratamento e controle de tratamento de riscos.
Gerenciamento das Contrataes e Suprimentos (Aquisies): O objetivo
principal obter bens e servios externos organizao executora. Consiste do planejamentode aquisio, planejamento de solicitao, solicitao de propostas, seleo de fornecedores, e
administrao e encerramento de contratos.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
21/420
3. CMM Capability Maturity Model e CMMI
Em 1987, o Software Engineering Institute - SEI sob a coordenao de Watts
Humphrey gerou a primeira verso do que veio a se chamar de modelo CMM. Segundo
Humphey, 1997, o modelo era composto pelos documentos de maturidade de processo e o
questionrio de maturidade. Em 1991, o SEI evoluiu a estrutura de maturidade de processo
para o chamado Capability Maturity Model for Software - SW-CMM.
O SW-CMM baseado em cinco estgios de maturidade. Estes estgios so
caracterizados pela existncia (definio, documentao e execuo) de determinados
processos dentro da organizao que so chamados de reas-chave de Processos. A
qualidade da execuo do processo, o nvel de acompanhamento desta execuo, a adequao
dos processos ao projeto so alguns dos fatores medidos para determinar o nvel de
maturidade da organizao. As reas-chave de Processos podem ser classificadas de
acordo com a categoria do processo (gerncia, organizao e engenharia) e o seu nvel de
maturidade conforme descrito na Tabela 2 0.
Como decorrncia da evoluo do modelo SW-CMM, em 2000 foi lanado um
novo produto: o CMMI. O CMMI agrega, alm da representao por estgios, a
representao contnua. Ou seja, na representao contnua, existem as reas-chave de
Processos, mas essas no esto distribudas em nveis, elas que contm graus de
capacidade. Esses processos, assim como, o objetivo do alcance da capacidade nos processos,
devem ser selecionados pela organizao e evoludos de acordo com os objetivos
organizacionais.
A representao contnua representada por nveis de capacidade, perfis de
capacidade, estgio alvo, e estgio equivalente (relao dessa representao em relao a
representao por estgio) como princpios de organizao dos componentes do modelo.
Nesse modelo existem seis nveis de capacidade designados pelos nmero de 0 at 5 que
correspondem a nvel 0 - Incompleto, 1 - Executado, 2 - Gerenciado, 3- Definido, 4
Gerenciado Quantitativamente e 5 - Otimizado. Os componentes do modelo CMMI podem
ser agrupados em 3 categorias:
Objetivos especficos e genricos so componentes do modelo requeridos e so
considerados essenciais para que a organizao alcance a melhoria de processo;
Prticas especficas e genricas so componentes do modelo esperados e podem
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
22/420
ajudar a alcanar os objetivos especficos e genricos; e
Sub-prticas, produtos de trabalho tpico, extenso da disciplinas, elaborao de
prticas genricas, ttulos de prticas e objetivos ajudam a entender o modelo.
Nvel dematuridade
GerencialPlanejamento de projeto de
software
OrganizacionalReviso e controle pela gerncia
snior
EngenhariaEspecificao, design,
codificao, controle dequalidade
2 Superviso eacompanhamento de projetos
Garantia de qualidade desoftware
Gerncia de configurao de
software Gerncia de contrato desoftware
Gerncia de requisitos Planejamento do projeto de
software3 Coordenao entre grupos
Gerncia de softwareIntegrada
Definio do processo daorganizao
Foco no processo daorganizao
Programa de treinamento
Engenharia deproduto de software
Reviso porparceiros
4 Gerncia quantitativa deprocessos
Gerncia dequalidade de
software5 Gerncia da evoluo dosprocessos
Gerncia da evoluotecnolgica
Preveno dedefeitos
Tabela 2- reas-chave de processos do SW-CMM de acordo com o nvel de maturidade e a categoria deprocessos
O modelo tambm subdividido em reas de processos e tem quatro categorias
que so: Processos de Gerncia de Processo, Processos de Gerncia de Projeto, Processos deEngenharia e Processos de Apoio. A Tabela 3 mostra as reas-chave de processos dentro das
categorias do CMMI. Os grupos de rea de processo bsicos so os que esto em nvel 1.
Essas prticas so consideradas essenciais para alcanar o propsito da rea de processo. As
prticas avanadas so as que esto presentes nos nveis maiores do que 1.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
23/420
Categorias de processo Grupo de reade processo
Processos
Processos de Gerncia de Processo Bsico Foco no processo organizacional Definio do processo organizacional Treinamento organizacional
Avanado Execuo do processo organizacional Entrega e inovao organizacionalProcessos de Gerncia de Projeto Bsico Planejamento de projeto
Monitoramento e controle de projeto Gerncia de "contratos" com fornecedores
Avanado Gerncia de projeto integrada Gerncia de risco Gerncia de projeto quantitativa
Engenharia Desenvolvimento de requisitos Gerncia de requisitos Soluo tcnica Integrao de produto Verificao Validao
Processos de apoio Bsica Gerncia de configurao Garantia de qualidade de produto e processo Anlise e medio
Avanado Resoluo e anlise de deciso Resoluo e anlise de causa
Tabela 3 - Distribuio das reas-chave de processos no CMMI
4. NBR ISO/IEC 12207 Processos de Ciclo de Vida de Software
A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foicriado em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente,
fornecedor, desenvolvedor, mantenedor, operador, gerentes e tcnicos envolvidos com o
desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum
estabelecida na forma de processos bem definidos. Esses processos so classificados em trs
tipos: fundamentais, de apoio e organizacionais representado na Figura 3. Todos esses
processos, executados durante o projeto de software, conduzem a qualidade tanto do produto
quanto do processo.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
24/420
Devido prpria evoluo da rea de engenharia de software e da necessidade
sentida por vrios usurios da Norma, foi disponibilizado em 2001 um anexo que atualizou a
Norma incluindo e expandido processos. Um dos processos que foi expandido e, o foco
deste artigo, o de Gerncia que ganhou alguns processos (veja Figura 4) e passou a ter os
seguintes objetivos:
Gerncia organizacional: Tem como objetivo estabelecer os objetivos de
negcio da organizao e desenvolver o processo, produto, e recursos os quais quando usados
por um projeto na organizao ajudam a organizao a encontrar os seus objetivos de negcio.
Gerncia de projetos: Tem como objetivo identificar, estabelecer, coordenar,
e monitorar as atividades, tarefas e recursos necessrios de um projeto para produzir um
produto e/ou servio, dentro do contexto dos requisitos e restries do projeto.
Gerncia da qualidade: Tem como objetivo satisfazer o cliente atravs do
alcance dos seus requisitos.
Figura 3 - Processos da Norma NBR ISO/IEC 12207 - Processos deCiclo de Vida
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
25/420
Gerncia de risco: Tem como objetivo identificar, gerenciar e minimizar os
riscos de forma contnua.
Alinhamento organizacional: Tem como objetivo assegurar que os indivduos
na organizao compartilhem uma viso e cultura comum e o entendimento dos objetivos donegcio para que esses ajam conjunta e efetivamente.
Medio: Tem como objetivo coletar e analisar dados relacionados ao
desenvolvimento dos produtos e implementao dos processos dentro da unidade
organizacional, suportando o gerenciamento efetivo dos processo e demonstrando
objetivamente a qualidade dos produtos.
Gerncia do conhecimento: Tem como objetivo assegurar que o
conhecimento individual, informaes e perfis sejam coletados, compartilhados, reusados e
melhorados atravs da organizao.
5. RUP Rational Unified Model
Os processos do IBM Rational Unified Process ou RUP oferecem uma
abordagem prescritiva nas melhores prticas de engenharia de software. Eles descrevem que
faz o que, quando e como no desenvolvimento e instalao de software. Tem como
caractersticas ser dirigido a casos de uso, centrado na arquitetura, dirigido a risco e iterativo.
Os requisitos funcionais, descritos na forma de casos de uso direcionam a arquitetura do
cdigo executvel. Alm disso, o processo foca no esforo do time como elemento estrutural
e comportamental importante . A mitigao dos elementos de risco mais importantes feita
nas primeiras iteraes do ciclo de vida. E finalmente, RUP particiona o ciclo de
desenvolvimento de software em iteraes que produzem verses incrementais da aplicao.
Figura 4 - Processos de gerncia da NBRISO/IEC 12207 expandido atravs do seu anexo
(verso 2001)
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
26/420
As disciplinas do RUP esto relacionadas s melhores prticas de
desenvolvimento de software, mas tambm representam os papeis dos membros ou subgrupos
no time de desenvolvimento de software. Estas disciplinas so:
1. Modelagem de negcio
2. Requisitos
3. Anlise e Projeto
4. Implementao
5. Teste
6. Instalao
7. Gerenciamento de projeto
8. Ambiente
9. Configurao e gerenciamento de mudanas
Das disciplinas do RUP Rational Unified Model, estamos interessados na
relativa a gerenciamento de projetos (RUP PM). O RUP (Kruchten, 2000, citando RUP)
define gerenciamento de projetos de software como a arte de equilibrar objetivos que
competem entre si, gerenciando risco e ultrapassando restries de modo a entregar com
sucesso um produto que atinge as necessidades dos clientes (aqueles que requerem que o
software seja desenvolvido) e dos usurios.
Figura 5: Disciplinas do RUP (fonte: IBM RUP)
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
27/420
A disciplina RUP PM fornece:
1. Um modelo para gerenciar projetos intensivos de software
2. Regras prticas para planejamento, contratao e execuo e monitoramento de
projetos
3. Um modelo para gerenciar risco
Esta disciplina foca principalmente nos aspectos mais importantes de um
processo de desenvolvimento iterativo:
1. Gerenciamento de riscos
2. Planejamento de um projeto iterativo, atravs do ciclo de vida e atravs de uma
interao particular
3. Monitorao do progresso de um projeto iterativo, mtricasH vrias reas do gerenciamento de projetos que saem do escopo da disciplina
RUP PM, porm so cobertas por outras prticas, como o PMBOK:
Gerenciar pessoas: Contratao, treinamento, coaching (cobertas pela rea de RH
do PMBOK);
Gerenciamento do custo: Definio, alocao e assim por diante (est ligado a rea
de gerenciamento do custo do PMBOK); Gerenciamento de contratos: fornecedores e clientes (est ligado a rea de
gerenciamento das aquisies do PMBOK).
Dentre as principais caractersticas do RUP, no que se refere a gerenciamento
de projetos, podemos citar:
Especfico para a rea de gerenciamento de software;
Contm prticas de gerenciamento de projetos e de desenvolvimento de software;
Cobre somente alguns aspectos do gerenciamento de projetos;
prescritiva (e no descritiva);
As fases e iteraes so especficas para desenvolvimento de software.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
28/420
6. Comparao PMBOK, CMMI, RUP e NBR ISO/IEC 12207
A comparao ser feita dos modelos CMMI, RUP e NBR ISO/IEC em
relao as prticas de gerenciamento de projetos propostas pelo PMBOK, de modo a
analisarmos qual o grau de atendimento da engenharia de software em relao as prticas
executadas e consagradas como melhores prticas pelos profissionais em gerenciamento de
projetos.
PMBOK CMMI RUP NBR ISO/IEC 12207Integrao Gerncia de projetointegrada
Gerenciamento deProjetosRequerimentosInstalaoConfigurao egerenciamento demudanas
Gerncia organizacional
Escopo Planejamento deacompanhamentoGerncia de requisitos
Gerenciamento de projetoRequisitosConfigurao egerenciamento demudanas
Gerncia de projetoGerncia de Requisitos
Tempo Acompanhamento econtrole.Mas, no endereaespecificamente essaquesto.
Gerenciamento de projeto Gerncia de projeto.Mas, no endereaespecificamente essa questo.
Custo Acompanhamento econtrole.Mas, no endereaespecificamente essaquesto.
Sem mapeamento Gerncia de projeto.Mas, no endereaespecificamente essa questo.
Aquisio Gerncia de Contratos comfornecedores
Sem mapeamento No tem processos que trateespecificamente essa questo.Ela coberta na norma pela
Aquisio e Fornecimento e gerenciada da mesma formaque um projeto interno organizao.
Recursos Humanos A prpria concepo domodelo diz que devem seter habilidades paraexecutar, mas nomenciona explicitamente anecessidade degerenciamento de recursoshumanos atravs dosprojetos da organizao.
Sem mapeamentocompleto, embora defina aorganizao do projeto
Recursos HumanosGerncia do Conhecimento
Comunicao Gerncia de Configuraocobre parcialmente esse
Gerenciamento de projeto Gerncia de Configuraocobre parcialmente esse
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
29/420
processo.A prpria concepo domodelo diz que osprocessos devem sercomunicados, mas nomenciona explicitamente a
necessidade decomunicao dos produtosdo projetos para todos osenvolvidos.
processo.Mas, no mencionaexplicitamente esse processo
Risco Gerncia de Risco Gerenciamento de projeto Gerncia de RiscoGarantia deQualidade
Garantia de qualidade deproduto e processo
Gerenciamento de projetogerenciamento demudanas
Gerncia da Qualidade
Tabela 3 Comparativo PMBOK, CMM, RUP e NBR ISO/IEC 12207 em relao a
gerenciamento de projetos
7. Concluso
O PMBOK, por ser mais genrico, cobre processos no cobertos pelos modelos
RUP, NBR ISO/IEC 12207 e CMM. Estes tm includo prticas gerenciais nos processos de
software, porm, apesar de diversas pesquisas evidenciarem que o problema gerencial e no
tcnico isso no est sendo representado devidamente nos modelos.
Para que a evoluo dos modelos possa reduzir a quantidade de falhas no
desenvolvimento de software importante o investimento em mtodos de gerenciamento mais amplos
e na profissionalizao das organizaes.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
30/420
Engenharia de Software, 2006 Jair C Leite
Planejamento e Gerenciamento deProjeto de Software
Definio das atividades
Estimativas e Mtricas
Dimensionamento do software
Clculo do esforo
Anlise dos Riscos
Definio Equipe Alocao de tarefas
Cronograma
Oramento
Engenharia de Software, 2006 Jair C Leite
O processo de desenvolvimento
prazos
custos
ferramentas
atividades
equipe
tempo
Situaoatual
Situaofutura
Software
modelos, prottipose documentos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
31/420
Engenharia de Software, 2006 Jair C Leite
Planejamento e Gerenciamento
Planejamento Previso de atividades, recursos, custos e prazos
Estimativas do produto e processo
Gerenciamento
Controle de acordo com o que foi planejado
Verificao da qualidade do produto e do processo
prazos
custos
ferramentas
atividades
pessoal
tempo
Software
modelos, prottipose documentos
previso controle
Planejamento
Gerenciamento
Engenharia de Software, 2006 Jair C Leite
Caractersticas do Planejamento e
Gerenciamento de Software
Dificuldades O software intangvel
No h um processo de software padro
A ES no possui a mesma tradio e status deoutras engenharias civil, mecnica e eltrica.
Grandes projetos de software so freqentementenicos.
Aspectos comuns Tcnicas de planejamento e gerenciamento so
amplamente aplicadas em diversas reas
Planejamento e gerenciamento so atividadescomuns em outras engenharias
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
32/420
Engenharia de Software, 2006 Jair C Leite
Planejamento
ferramentas
atividades
tempo
Situaoatual
Situaofutura
Software
modelos, prottipose documentos
modelo deprocesso
Requisitos
planejamento
Cronograma: prazos
Oramento: custos
Equipe: pessoal
Engenharia de Software, 2006 Jair C Leite
Principais atividades
Elaborao de propostas
Planejamento e cronograma de projeto
Oramento do projeto
Monitoramento e revises
Seleo e avaliao de pessoal
Elaborao de relatrios e apresentaes
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
33/420
Engenharia de Software, 2006 Jair C Leite
Planejamento
Totalizao dos custosElaborar oramento
Estimativas de produtividade,restries de prazos e custos,disponibilidade de pessoal eferramentas
Elaborar cronograma
Estimativas do produto e restriesde prazos e custosAlocao de pessoa-tarefa(atividade)
De acordo com atividades,
capacidade do pessoal , prazos ecustos
Definir equipe
De acordo com atividades e custosEscolher ferramentas
Modelo de processoDeterminar atividades
Como?O que?
Engenharia de Software, 2006 Jair C Leite
Gerenciamento e Avaliao
Gerenciamento do Processo
Os prazos esto sendo cumpridos?
Os custos esto dentro do oramento?
A equipe obedece alocao de tarefas?
As ferramentas esto adequadas?
As atividades esto sendo realizadas com planejadas?
Avaliao do produto
Os modelos, prottipos e documentos esto sendoproduzidos com qualidade?
O software produzido tem qualidade?
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
34/420
Engenharia de Software, 2006 Jair C Leite
Qualidades do processo e produto
prazos
custos
atividades
equipe
tempo
Software
modelos, prottipose documentos
Mtricasdo produto
Mtricasdo processo
Qualidade do processo e do produtoGerenciamento
Avaliao
Engenharia de Software, 2006 Jair C Leite
Estrutura de um plano de projeto
Introduo
Organizao de projeto
Anlise de riscos
Requisitos necessrios de hardware e
software Estrutura analtica de trabalho
Cronograma de projeto
Mecanismos de monitoramento e elaborao
de relatrios
[Ian Sommerville]
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
35/420
Engenharia de Software, 2006 Jair C Leite
Tipos de planos
Plano de projeto de software Descreve as atividades, equipe, oramento, cronograma,
recursos, etc.
Plano de qualidade Descreve os procedimentos de testes de qualidade que
sero utilizados
Plano de validao Descreve a abordagem, os recursos e o mtodo utilizados
pa validao
Plano de manuteno Prev requisitos, custos e esforo necessrio para a
manuteno
Plano de desenvolvimento da equipe Descreve como as habilidades e a experincia sero
desenvolvidas
Engenharia de Software, 2006 Jair C Leite
Modelo de Plano de Desenvolvimento
de Software
Introduo
Organizao do Projeto
Processo Gerencial
Processo Tcnico
Cronograma e Oramento
Padro IEEEMtodo Prxis
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
36/420
1
CI nCI n--UFPEUFPE 112001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Engenharia de SoftwareEngenharia de Software
Requisitos de Software
CI nCI n--UFPEUFPE 222001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Requisitos de softwareRequisitos de software
n Descrio e especificao de um sistema
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
37/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
38/420
3
CI nCI n--UFPEUFPE 552001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Exemplos de requisitos funcionaisExemplos de requisitos funcionais
n O usurio deve ser capaz de pesquisar tanto todo oconjunto inicial do banco de dados ou selecionar umsubconjunto dele.
n O sistema deve fornecer visualizadores (viewers)apropriados para ler documentos.
n Para cada pedido deve ser alocado um identificador nico
(ORDER_ID).
CI nCI n--UFPEUFPE 662001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Impreciso dos requisitosImpreciso dos requisitos
n Problemas surgem quando os requisitos no sodeclarados precisamente
n Requisitos ambguos podem ser interpretados de formadiferente por desenvolvedores e usurios
n Considere o termo visualizadores apropriadosu Inteno do usurio - visualizadores de propsito especial para
cada tipo de documento diferenteu Interpretao do desenvolvedor - um visualizador textual que
mostra o contedo do documento
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
39/420
4
CI nCI n--UFPEUFPE 772001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Requisitos noRequisitos no--funcionaisfuncionais
n Requisitos de produtou Requisitos que especificam que o produto entregue tem que se
comportar de um modo particular. Por exemplo, velocidade deexecuo, confiabilidade, etc.
n Requisitos organizacionaisu Requisitos que so uma conseqncia de polticas e
procedimentos organizacionais. Por exemplo, padres deprocessos usados, requisitos de implementao, etc.
n Requisitos externosu Requisitos que surgem de fatores que so externos ao sistema e
ao seu processo de desenvolvimento. Por exemplo, exigncias deinteroperabilidade, requisitos legislativos, etc.
CI nCI n--UFPEUFPE 882001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Tipos de requisitos no funcionaisTipos de requisitos no funcionais
Performancerequirements
Spacerequ irements
Usabilityrequirements
Efficiencyrequir ements
Reliabilityrequir ements
Portabilit yrequirements
Interoperabil ityrequirements
Ethicalrequirements
Legis lativerequirements
Impl ementat ionrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Pro ductrequir ements
Org anizatio nalrequirements
Externalrequirements
Non-functio nalrequirements
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
40/420
5
CI nCI n--UFPEUFPE 992001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Interao entre requisitosInterao entre requisitos
n Conflitos entre requisitos no funcionais diferentes socomuns em sistemas complexos
n Exemplo: em um sistema de uma nave espacialu Para minimizar o peso, a quantidade de chips no sistema deve ser
minimizadau Para minimizar o consumo de energia, chips de baixo consumo
devem ser utilizados
u Contudo, o uso de chips de baixo consumo significa que maischips vo ter que ser usados. Qual o requisito mais crtico
CI nCI n--UFPEUFPE 10102001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Problemas com especificao em LNProblemas com especificao em LN
n Falta de clarezau Preciso difcil sem tornar o documento difcil para leitura
n Confuso de requisitosu Requisitos funcionais e no funcionais tendem a ser misturados
n Fuso de requisitosu Vrios requisitos diferentes podem ser expressos juntos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
41/420
6
CI nCI n--UFPEUFPE 11112001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Problemas com especificao em LNProblemas com especificao em LN
n Ambigidadeu Os leitores e escritores do requisito devem interpretar as mesmas
palavras da mesma maneira. LN naturalmente ambgua o que torna oseu uso muito difcil.
n Flexibilidadeu A mesma coisa pode ser dita de vrias formas diferentes na
especificao
n
Falta de modularizaou Estruturas de LN so inadequadas para estruturar requisitos do s isteman Concluso: Necessidade de uma notao mais
apropriada
CI nCI n--UFPEUFPE 12122001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
O documento de requisitosO documento de requisitos
n O documento de requisitos a documentao oficial doque requerido dos desenvolvedores do sistema
n Deve incluir tanto a definio como a especificao dosrequisitos
n Ele NO um documento de projeto. Na medida dopossvel, ele deve definir O QUE o sistema deve fazer emvez do COMO ele deve fazer
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
42/420
7
CI nCI n--UFPEUFPE 13132001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Usurios de um documento de requisitosUsurios de um documento de requisitos
Use t he req uirements todevelop validation tes ts forthe s ystem
Use the requirementsdocument to plan a bid for
the system and to plan thesystem deve lo pment process
Use the requirements tounderstan d what sys tem is tobe developed
System tes tengineers
Managers
System engineers
Specif y the requirements andread them to che ck that t hey
meet their needs. The yspecify ch anges to th erequiremen ts
System customers
Use the requirements to help
understand the system andthe relati onship s betw een itsparts
Systemmaintenance
engineers
CI nCI n--UFPEUFPE 14142001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
ElicitaoElicitao de Requisitosde Requisitos
n ELICITAR: descobrir, tornar explcito, obter o mximode informaes para o conhecimento do objeto emquesto
n Cabe elicitao a tarefa de identificar os fatosrelacionados aos requisitos do Sistema, de forma aprover o mais correto e mais completo entendimentodo que demandado daquele software
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
43/420
8
CI nCI n--UFPEUFPE 15152001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
ElicitaoElicitao de Requisitos: Dificuldadesde Requisitos: Dificuldades
n Usurios podem no ter uma idia precisa do sistema por elesrequerido;
n Usurios tm dificuldades para descrever seu conhecimentosobre o domnio do problema;
n Usurios e Analistas tm diferentes pontos de vista do problema(por terem diferentes formaes);
n Usurios podem antipatizar-se com o novo sistema e se negarema participar da elicitao (ou mesmo fornecer informaes
errneas).
CI nCI n--UFPEUFPE 16162001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Componentes daComponentes da elicitaoelicitao de requisitosde requisitos
Application
domain
Stakeholderneeds andconstraints
Problem to be
solved
Businesscontext
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
44/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
45/420
10
CI nCI n--UFPEUFPE 19192001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
O processo daO processo da elicitaoelicitao de requisitosde requisitos
Businessgoals
System
constraints
Problem to besolved
Establish objectives Understand background
Organisationalstructure
Applicationdomain
Existing
systems
Stakeholderidentification
Goalprioritisation
Domain
knowledgefiltering
Organise knowledge
Stakeholderrequirements
Collect requirements
Domainrequirements
Organisational
requirements
CI nCI n--UFPEUFPE 20202001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Estgios daEstgios da ElicitaoElicitao
n Definio dos objetivosu Os objetivos organizacionais devem ser estabelecidos incluindo
objetivos gerais do negcio, um descrio geral do problema a serresolvido, porque o sistema necessrio, e as limitaes do sis tema.
n Aquisio de conhecimento do backgroundu Informao de background do sistema: inclui informao acerca da
organizao onde o sistema ser instalado, o domnio de aplicao dosistema, e informao acerca de outros sistemas existentes
n Organizao do conhecimentou A grande quantidade de conhecimento que foi coletada nos estgios
anteriores deve ser organizada e colocada em ordem.
n Coleta dos requisitos dos stakeholdersu Os stakeholders do sistema so consultados para descoberta de seus
requisitos.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
46/420
11
CI nCI n--UFPEUFPE 21212001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Anlise e negociao de requisitosAnlise e negociao de requisitos
Necessitychecking
Consistency andcompleteness
checking
Feasibilitychecking
Unnecessaryrequirements
Confli cting andincomplete
requirements
Infeasiblerequirements
Requirementsdiscussion
Requirementsprioritisation
Requirementsagreement
Requirements analysis
Requ irements negotiation
CI nCI n--UFPEUFPE 22222001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Anlise dos requisitosAnlise dos requisitos
n Verificao da necessidadeu A necessidade os requisitos analisada. Em alguns casos, alguns
requisitos propostos podem no contribuir para os objetivos de negcioda organizao ou para o problema especfico tratado pelo sistem a.
n Verificao de consistncia e completudeu Os requisitos so verificados entre si para determinar consistncia e
completude. Consistncia significa que nenhum requisito deve sercontraditr io; completude significa que nenhum servio (ou limitao)que seja necessrio foi esquecido.
n Verificao de viabilidadeu Os requisitos so verificados para garantir que so viveis dentro do
oramento e tempo disponvel para o desenvolvimento do sistema.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
47/420
12
CI nCI n--UFPEUFPE 23232001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Negociao dos requisitosNegociao dos requisitos
n Discuo dos requisitosu Os requisitos que foram identificados como problemticos so
discutidos e os stakeholders envolvidos apresentam seus pontosde vista acerca dos requisitos.
n Priorizao dos requisitosu Os requisitos disputados so priorizados para identificar requisitos
crticos e ajudar o processo de tomada de deciso.
n Concordncia dos requisitosu Solues para os problemas dos requisitos so identificadas e um
conjunto de requisitos so acordados. Geralmente isto envolvemudanas em alguns dos requisitos.
CI nCI n--UFPEUFPE 24242001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Tcnicas deTcnicas de ElicitaoElicitao
n Tcnicas especiais que podem ser usadas para coletarconhecimento sobre os requisitos dos usurios
n Este conhecimento deve ser estruturadou Particionamento - agregando conhecimentos relacionadosu Abstrao - reconhecendo generalidadesu Projeo - organizando de acordo com uma perspectiva
n Problemas da elicitaou No existir muito tempo para a elicitaou Preparao inadequada dos engenheirosu Stakeholders no estarem convencidos da necessidade de um
novo sistema
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
48/420
13
CI nCI n--UFPEUFPE 25252001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Algumas tcnicas deAlgumas tcnicas de elicitaoelicitao
n Entrevistasn Leitura de documentosn Questionriosn Cenriosn Observaes e anlise sociais (etnografia)n Reuso de requisitosn Prototipagem
CI nCI n--UFPEUFPE 26262001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
n O profissional de ER deve selecionar as tcnicas a seremutilizadas e estabelecer de que maneira elas serointegradas
n importante utilizar uma tcnica de modelagem de apoio
para que os fatos elicitados fiquem corretamenterepresentados para futuro tratamenton A escolha das tcnicas e seu esquema de integrao
depender do problema e da equipe participanten O ponto importante ter conhecimento sobre estas
tcnicas e identificar onde uma tcnica superior a outra
ElicitaoElicitao de Requisitosde Requisitos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
49/420
14
CI nCI n--UFPEUFPE 27272001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Tcnicas deTcnicas de ElicitaoElicitao
n Sempre perguntar: o que? Por que(m)? Como?n Pergunte o bvion Organize as respostas: durante versusdepoisn Observen Estudar o que? Por que? Onde comearn Seja humilde, procure aprender!
CI nCI n--UFPEUFPE 28282001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
CenriosCenrios
n Cenrios so estrias que explicam como um sistema poder serusado. Eles devem incluir:u uma descrio do estado do sistema antes de comear o cenriou o fluxo normal de eventos do cenriou excees ao fluxo normal de eventos
u informaes sobre atividades concorrentesu uma descrio do estado do sistema ao final do cenrio
n Cenrios so exemplos de sesses de interao que descrevemcomo o usurio interage com o sistema
n A descoberta de cenrios expe interaes possveis do sistema erevela as facilidades que o sistema pode precisar
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
50/420
15
CI nCI n--UFPEUFPE 29292001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Cenrios e Projeto OOCenrios e Projeto OO
n Cenrios so partes inerentes de alguns mtodos dedesenvolvimento orientados a objeto
n O termo caso de uso ou use-case (um caso especficodo uso do sistema) usado s vezes para se referir a umcenrio
CI nCI n--UFPEUFPE 30302001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Cenrio de um sistema de livraria virtualCenrio de um sistema de livraria virtual
n Entre no sisteman Escolha o comando pedido de documentosn Entre um nmero de referncia do documento pedidon Selecione um ponto de entregan Saia do sistema
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
51/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
52/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
53/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
54/420
19
CI nCI n--UFPEUFPE 37372001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Anlise de requisitosAnlise de requisitos
n O objetivo da anlise descobrir problemas,incompletude e inconsistncia nos requisitos elicitados.Eles normalmente so retornados aos stakeholders pararesolv-los, atravs de um processo de negociao
n A anlise intercalada com elicitao, pois problemasso descobertos quando os requisitos so elicitados
n
Uma lista de verificao de problemas poder ser usadapara ajudar a anlise. Cada requisito poder ser avaliadocontra esta lista
CI nCI n--UFPEUFPE 38382001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Lista de verificao da anliseLista de verificao da anlise
n Projeto prematurou Os requisitos incluem informao prematura de projeto ou
implementao?
n Requisitos combinadosu A descrio do requisito descreve um requisito nico ou este pode ser
descrito em vrios requisitos diferentes?
n Requisitos desnecessriosu O requisito realmente necessrio, ou ser que uma mera adio
cosmtica ao sistema?
n Uso de hardware no padronizadou Os requisitos implicam no uso de uma plataforma de hardware no
padronizada? Para tomar esta deciso, voc precisa conhecer osrequisitos de plataforma do computador.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
55/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
56/420
21
CI nCI n--UFPEUFPE 41412001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Matrizes de InteraoMatrizes de Interao
Requirement R1 R2 R 3 R4 R5 R6
R1 0 0 1 000 0 1 1
R2 0 0 0 0 0 0
R3 1000 0 0 1000 0 1000
R4 0 0 1 000 0 1 1
R5 1 0 0 1 0 0
R6 1 0 1 000 1 0 0
CI nCI n--UFPEUFPE 42422001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Negociao de requisitosNegociao de requisitos
n Problemas nos requisitos so inevitveis quando umsistema possui muitos stakeholders. Conflitos no sofalhas, mas refletem necessidades e prioridadesdiferentes entre as partes interessadas
n
A negociao de requisitos o processo de discussodos conflitos de requisitos e a busca de um compromissono qual todas as partes interessadas concordem
n No planejamento do processo de engenharia derequisitos, importante deixar bastante tempo paranegociao. Alcanar um compromisso aceitvel podetomar um tempo considervel
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
57/420
22
CI nCI n--UFPEUFPE 43432001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Encontros de negociaoEncontros de negociao
n Um estgio de informao onde a natureza dosproblemas associados com os requisitos so explicados.
n Um estgio de discusso onde as partes interessadasdiscutem como o problema poder ser resolvido.u Todas as partes interessadas no requisito devem ter a
oportunidade de comentar. Neste estgio so atribudasprioridades aos requisitos.
n Estgio de resoluo onde as aes que dizem respeitoao requisito so concordadas.u Estas aes podem ser: deletar o requisito, sugerir modificaes
ao requisito ou elicitar mais informaes sobre o requisito.
CI nCI n--UFPEUFPE 44442001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos
Pontos principaisPontos principais
n Requisitos definem o que sistema deve fazer e asrestries sobre suas operaes e implementao
n Requisitos funcionais definem os servios que os sistemadeve fornecer
n Requisitos no funcionais restringem o sistema que estsendo desenvolvido ou o processo de desenvolvimento
n O documento de requisitos a especificao para osclientes, engenheiros e gerentes
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
58/420
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
59/4201
Prof. Cristiano R R [email protected]
Engenharia de Software
Tema da Aula
Projeto de Software
Engenharia deSoftware
Projeto (Design) de Software
Projetar Software o processo de aplicar vrias tcnicas e
princpios com o propsito de se definir um dispositivo,
processo ou sistema, com detalhes suficientes para permitir
sua realizao fsica. (Taylor-59).
O Projeto de software o ncleo tcnico da Engenharia de
Software. a nica maneira de se traduzir "com preciso", os
requisitos do usurio para um produto ou sistema acabado.
Meta:
Traduzir requisitos numa representao de software.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
60/4202
Engenharia deSoftware
Projeto (Design) de Software
Princpios
Desenvolver um projeto de software um processo quecombina:
Instituio de critrios baseados na experincia adquirida naconstruo de entidades similares.
Um conjunto de princpios e/ou heursticas que guiam odesenvolvimento do modelo.
Um conjunto de critrios que facilitam a verificao da
qualidade. Um processo de iterao que conduz a uma representao
do projeto final
Engenharia deSoftware
Projeto (Design) de SoftwareDiferentes Vises
' Projeto Procedimental: descrio da funcionalidade dosoftware (algoritmos).
' Projeto de Dados: definio das estruturas de dados.
' Projeto das Interfaces: Layouts e mecanismos deinterao homem-mquina (se necessrio).
' Projeto Arquitetural: associao entre os principaiselementos estruturais do software (rvore dos mdulos,mensagens entre objetos, Nivelamento em Camadas).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
61/4203
Engenharia deSoftware Projeto (Design) de SoftwareTransio Anlise -> Projeto
Dados tratados pelo sistema
Como os dados so tratados
Como o sistema reage a eventos
Engenharia deSoftware
Projeto (Design) de SoftwareModelo Clssico (Cascata)
Projeto de Software:
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
62/4204
Engenharia deSoftware Projeto (Design) de SoftwareModelo Clssico (Cascata)
Projeto de Software:
Engenharia deSoftware
Processo (Design) de Software
'Projeto Preliminar
Transformao dos requisitos em modelos de
arquitetura, dados e procedimentos.
'Projeto Detalhado
Refinamento da representao da arquitetura, dosdados e dos procedimentos, gerando estruturas maisrefinadas (detalhadas).
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
63/4205
Engenharia deSoftware Qualidade do Projeto de Software
'A Qualidade do Projeto avaliada atravs derevises tcnicas formais (walkthrougs deprojetos), usando-se os seguintes critrios dereferncia:
1. Organizao hierrquica: atravs do uso inteligentede controle entre os elementos do software;
2. Modularidade: particionamento lgico em elementosque executam funes e subfunes especficas;
Engenharia deSoftware
Qualidade do Projeto de Software
' A Qualidade do Projeto avaliada ...
3. Representaes distintas para dados e procedimentos:mesmo que sejam posteriormente agrupados em objetos;
4. Deve levar a Mdulos ou Classes de objetos queapresentam caractersticas funcionais independentes;
5. Deve levar interfaces que reduzam a complexidade deconexes entre os mdulos e com o ambiente externo; e
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
64/4206
Engenharia deSoftware Fundamentos do Projeto de Software
Fundamentos:
1. Abstrao: Concentrar-se no problema com um certo nvelde generalizao.Abstrao procedimental
Abstrao de dados
2. Refinamento sucessivo: um processo de elaboraoque parte de uma declarao de funo, que serelaborada atravs de sucessivos refinamentos, cada umincorporando mais detalhes.
Abstrao do Projetoe de seu ambiente
Engenharia deSoftware
Fundamentos do Projeto de Software
3. Modularidade:
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
65/4207
Engenharia deSoftware Projeto de Software
Engenharia deSoftware
Fundamentos do Projeto de Software
4. Arquitetura de Software: Estrutura hierrquica de componentes procedimentais e Estrutura de dados
5. Hierarquia de Controle:Representa a organizao de componentes de um programa e
a hierarquia de controle entre seus mdulos.
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
66/4208
Engenharia deSoftware
Projeto Procedimental de SoftwareDiagrama Estrutura - Hierarquia dos Mdulos
Engenharia deSoftware
Projeto Procedimental de SoftwareDiagrama Estrutura - Hierarquia dos Mdulos
Deciso: o mdulo
abaixo pode ou no
receber o controle
(deciso).
Chamada repetida
(iterativa)
Passagem de dados
entre mdulos
Passagem de controle
entre mdulos
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
67/4209
Engenharia deSoftware Projeto de Dados de Software
Projeto de Dados
Engenharia deSoftware
Projeto de Dados de Software
Representao do relacionamento lgico entreelementos de dados individuais. Determina aorganizao, mtodos de acesso, associaes e
alternativas de processamento.
'Parte dos dados levantados e representados na fasede anlise: Dicionrio de Dados Fluxo, Contedo e Estrutura
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
68/42010
Engenharia deSoftware Projeto de Dados de Software
Atividades do Projeto de Dados:
'Selecionar representaes de dados;
'Estudar e escolher estruturas de dados quepermitam a implementao mais adequada;
'Caracterizar a Abrangncia (escopo) dos Dados Local (componente), Partes do software ou Global
Caracterizas a Persistncia dos Dados Persistentes (B.Dados) No Persistentes (Dados em memria, estruturas de
manipulao/intermediria)..
Engenharia deSoftware
Projeto de Dados de Software
Estruturas/Elementos de DadosComuns:
'Itens Elementar (Tipos Primitivos)
'Listas Lineares
Gerais Pilhas Filas
'Lista no lineares rvores Grafo
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
69/42011
Engenharia deSoftware
Projeto de Dados de Software
Dados Persistentes
Modelo de Entidade-Relacionamento (MER)
Entidades Relacionamentos
Atributos
Engenharia deSoftware
Projeto de Software
Projeto Arquitetural de Software
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
70/42012
Engenharia deSoftware Projeto Arquitetural de Software
Visa modelar a estrutura completa do software e as maneirasfornecidas para manter a integridade conceitual de umsistema:
Arquiteturas Tradicionais: Centralizada Parcialmente Distribuda Cliente-Servidor (2 Camadas)
Cliente-Servidor (3 Camadas) Distribuda (Multi-Camadas)
Engenharia deSoftware
Projeto Arquitetural de SoftwareArquitetura Centralizada
' Caractersticas: Processamento centralizado no Mainframe; Terminais Burros (sem processamento); Redes Corporativas; Software uso Departamental (Baixa Integrao).
Terminal burro
Mainframe
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
71/42013
Engenharia deSoftware
Projeto Arquitetural de Software
Arquitetura Parcialmente Distribuda
Caractersticas: Um pouco de processamento departamental; Micros com algumas aplicaes locais; Rede Corporativa conectando micro-mainframe; Software Departamental com maior Integrao; Incio de Integrao entre parceiros (EDI).
Mainframe
Microcomputador
Engenharia deSoftware
Projeto Arquitetural de SoftwareCliente-Servidor (2 camadas)
Caractersticas: Boa parte do processamento local Micros com algumas aplicaes locais Redes LANs ou WANs Integrao entre Parceiros (cliente-servidor)
Micro Cliente
Servidor
Cliente
ClienteCliente
Rede
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
72/42014
Engenharia deSoftware
Projeto Arquitetural de Software
Cliente-Servidor 3 camadas
Client Side
(Camada 1)
Camada de Rede
Sockets e
Midleware
Server Side
Regras Negcio Bases de Dados
(Camada 2) (Camada 3)
Caractersticas: Mais capacidade de Processamento Distribudo Internet/Intranet como infra-estrutura de rede 2 Nveis de Servidor Internet Aplications / Software Integrados(ERPs)
Servidorde
Aplicaes
Servidorde Bases
de DadosCliente
Engenharia deSoftware
Projeto Arquitetural de SoftwareArquitetura Distribuda Multi-Camadas
Client Side
(Camada 1)
Camada de Rede
Sockets e
Midleware
Cliente
Regras Negcio Bases de Dados
(Camada 2 e 1) (Camada 3)
Servidor de
Aplicaes
Servidorde Bases
de Dados
Servidor deAplicaes
Servidorde Basesde Dados
Browser
Regras de
Negcio
Bases de
Dados
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
73/42015
Engenharia deSoftware
Projeto Arquitetural de Software
Arquitetura Distribuda Multi-Camadas
'Caractersticas:
Alta Capacidade de Processamento Distribudo
Internet/Intranet/Extranet/VPNs como infra-estrutura de rede
Distribuio dos Servios em vrias camadas de servidoresde aplicao e dados
Internet Aplications de ltima gerao, CRM (Relacionamentocom Cliente), SCM (Cadeias de Produo e Distribuio
Integradas), Bancos de Dados Distribudos
Engenharia deSoftware
Projeto de Software
Projeto Procedimental
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
74/42016
Engenharia deSoftware Projeto Procedimental de Software
Finaliza os detalhes de processamento (procedimentos) decada mdulo. O procedimento deve oferecer umaespecificao precisa do processamento, inclusive aseqncia de eventos, operaes repetitivas etc.
Baseia-se na Especificao dos requisitos, na modelagem(DFD, Diagrama Classes) e no Dicionrio de Dados,obtidos na anlise.
Engenharia deSoftware
Projeto Procedimental de SoftwareModelo Comportamental
Diagrama de Estados dos Exemplares
-
8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos
75/42017
Engenharia deSoftware Projeto Procedimental de Software
Seqncia:
1. Decomposio, Identificao e Modelagem do softwareatravs de Componentes (Mdulos ou Classes)
2. Representao da estrutura de controle e interao entreos componentes
3. Reviso e Refinamento da Estrutura
4. Representao dos detalhes algortmicos
Engenharia deSoftware
Projeto Procedimental de Software
Estrutura do mdulo Monitorar Sensores
-
8/6/2019 TI - Conhecimentos Esp