JEDI

TM
2. Engenharia de Software - Uma viso em camadas
Engenharia de Software uma disciplina que aplica princpios da engenharia de
desenvolvimento na qualidade do software em um determinado tempo e com um custo efetivo.
Usando uma abordagem sistemtica e metodolgica para produzir resultados que possam ser
quantificados. Faz uso de medio e mtricas para avaliar a qualidade, no somente do software,
mas tambm do processo. Utilizada para avaliar e gerenciar projetos de desenvolvimento de
software.
Engenharia de Software vista de modo diferente pelos diversos profissionais. Pressman sugere
uma viso da engenharia de software como uma camada tecnolgica
1
. Essa viso consiste em
quatro camadas: foco na qualidade, processo, mtodo e ferramentas. A Figura 1 ilustra essa viso
da engenharia de software.
Figura 1: Engenharia de Software - Uma camada de viso
2.1. Foco na Qualidade
Essa camada busca um total foco na qualidade. uma cultura onde o compromisso em
melhoria continua no processo de desenvolvimento do software sustentado. Permite o
desenvolvimento de mais abordagens efetivas para engenharia de software.
2.2. Processo
Define uma estrutura, que consiste em reas de processos chave, que define e permite a entrega
racional e a tempo de um software. reas de processos chave so a base para o gerenciamento
de projeto de software. Estabelecem que mtodos tcnicos sejam aplicados, quais ferramentas
so usadas, que produtos de trabalho precisam ser produzidos, e que marcos so definidos.
Incluem a garantia que a qualidade ser mantida, e que a mudana devidamente controlada e
gerenciada.
2.3. Mtodo
Mtodos definem procedimentos sistemticos e ordenados de construo de software. Eles
proporcionam uma estrutura global interna onde as atividades do engenheiro de software so
realizadas. Essas atividades incluem um conjunto amplo de tarefas, tais como, anlise de
requisitos, design, construo do programa, teste e manuteno.
Metodologia a cincia de pensamento sistemtico, usando os mtodos ou procedimentos para
uma disciplina em particular. Existem vrias metodologias da engenharia de software que so
usadas atualmente. Algumas delas esto enumeradas abaixo:
Metodologias Estruturadas:
Informaes de Engenharia
Desenvolvimento do Ciclo de Vida do Software/Ciclo de Vida do Projeto
Metodologia de Desenvolvimento de Aplicao Rapid
Metodologia de Desenvolvimento de Aplicao Joint
Mtodo CASE*
1 Pressman, Roger S., Software Engineering, A Practitioner's Approach, Sixth Edition, (Singapore: McGraw-Hill Internal Edition, 2005), p. 53-54
Engenharia de Software 5
Foco na Qualidade
Processo
Mtodo
Ferramentas
JEDI
TM
Metodologias Orientadas a Objeto:
Mtodo Booch
Mtodo Coad e Yourdon
Mtodo Jacobson
Mtodo Rambaugh
Mtodo Wirfs-Brock
2.4. Ferramentas
Promovem o suporte aos processos e mtodos. Ferramentas CASE (Computer Aided Software
Engineeing) proporcionam um sistema de suporte ao projeto de desenvolvimento, onde as
informaes criadas por uma ferramenta podem ser usadas por outras. Podem ser automticas ou
semi-automticas.
Muitas ferramentas so usadas para desenvolver modelos. Modelos so patterns (padres) de
algo que foi criado ou so simplificaes. Existem dois modelos que geralmente so desenvolvidos
por um engenheiro de software, especialmente, o modelo de sistema e o modelo de software. O
modelo de sistema uma representao acessvel de um sistema complexo que precisa ser
estudado, enquanto o modelo de software chamado de blueprint do software que precisa ser
construdo. Assim como as metodologias, vrios modelos de ferramentas so usados para
representar sistemas e softwares. Alguns esto descritos abaixo.
Abordagem de Modelos de Ferramentas Estruturada:
Diagrama de Entidade-Relacionamento
Diagrama de Fluxo de Dados
Pseudocdigo
Fluxograma
Abordagem de Modelo de Ferramenta Orientada a Objeto:
Linguagem de Modelagem Unificada (UML)
Engenharia de Software 6
JEDI
TM
3. Qualidade dentro do Esforo de Desenvolvimento
Conforme mencionado anteriormente, a qualidade a mente que influencia todo engenheiro de
software. Focando na qualidade em todas as atividades de engenharia de software, reduz-se
custo e melhora-se o tempo de desenvolvimento pela minimizao de um novo trabalho de
correo. Para proceder dessa forma, um engenheiro de software tem que definir explicitamente
que qualidade de software ter um conjunto de atividades que asseguraro que todo produto de
trabalho da engenharia de software exibe alta qualidade, fazer controle de qualidade e atividades
garantidas, o uso de mtricas para desenvolver estratgias para melhorar o produto de software e
o processo.
3.1. O que qualidade?
Qualidade a caracterstica total de uma entidade para satisfazer necessidades declaradas e
implcitas. Essas caractersticas ou atributos tm que ser mensurveis de modo que possam ser
comparados por padres conhecidos.
3.2. Como definimos qualidade?
Trs perspectivas so usadas na compreenso da qualidade, especialmente, olhamos para a
qualidade do produto, do processo e no contexto do ambiente de negcios
2
.
Qualidade do Produto
Significa coisas diferentes para cada pessoa. relativo para uma pessoa analisar qualidade. Para
os usurios finais, o software tem qualidade se fornecer o que desejam e quando desejam o
tempo todo. Tambm julgam baseados na facilidade de usar e de aprender como us-lo.
Normalmente avaliam e categorizam com base em caractersticas externas, tal como, nmero de
falhas por tipo. Falhas podem ser categorizadas como: insignificantes, importantes e
catastrficas. Para que outros possam desenvolver e manter o software, estes devem ficar de olho
nas caractersticas internas em vez das externas. Exemplos que incluem erros e falhas
encontradas durante as fases de anlise de requisitos, design, e codificao so normalmente
feitos anteriormente ao carregamento dos produtos para os usurios finais.
Como engenheiros de software, devemos construir modelos baseados em como os requisitos dos
usurios externos sero relacionados com os requisitos internos dos desenvolvedores.
Qualidade do Processo
Existem vrias tarefas que afetam a qualidade do software. s vezes, quando uma tarefa falha, a
qualidade do software falha. Como engenheiros de softwares, devemos validar a qualidade no
processo de desenvolvimento do software. Regras de processo sugerem que pela melhoria do
processo de desenvolvimento do software, tambm h melhora da qualidade do produto
resultante. Algumas regras de processo so demonstradas abaixo:
Capability Maturity Model Integration(CMMI). Foram formulados pelo Software
Engineering Institute (SEI). um processo meta-modelo que baseado em um conjunto de
sistemas e competncias da engenharia de software que devem existir dentro de uma
organizao. Como a mesma atinge diferentes nveis de capacidade e maturidade desses
processos de desenvolvimento.
ISO 9000:2000 para Software. um padro genrico, aplicado para qualquer organizao
que queira melhorar a qualidade global dos produtos, sistemas ou servios que proporciona.
Software Process Improvement e Capability Determination (SPICE). um padro que
define um conjunto de requisitos para avaliao do processo de software. O objetivo desse
padro auxiliar organizaes a desenvolver uma anlise objetiva da eficcia de qualquer
processo de software definido.
Qualidade no contexto do ambiente de negcio
2 Pfleeger, Shari Lawrence, Software Engineering Theory and Practice, International Edition, (Singapore: Prentice-Hall, 1999), p. 10-14
Engenharia de Software 7
JEDI
TM
Nessa perspectiva, qualidade visualizada em termos de produtos e servios sendo
proporcionado pelo negcio em que o software usado. Melhorando a qualidade tcnica dos
processos de negcio, agrega-se valor ao negcio, por exemplo, valor tcnico do software traduz
o valor do negcio. Tambm importante medir o valor do software em termos de terminologias
de negcio, tal como, "quantos pedidos de venda foram processados hoje?, valor do dlar sobre
o retorno em cima dos investimentos (ROI), etc. Se o software no agrega valor ao negcio, qual
a necessidade de t-lo em primeiro lugar?
3.3. Como endereamos os pontos importantes sobre qualidade?
Podemos enderear os pontos importantes sobre qualidade em:
1. Uso de padres de Qualidade. Padres de qualidade so um conjunto de princpios,
procedimentos, metodologias e regras, para resumir, sobre qualidade no processo, tais
como, CMMI, ISO 9000:2000 para Software e SPICE.
2. Compreender pessoas envolvidas no processo de desenvolvimento incluindo
usurios finais e participantes. Sustenta um ambiente de colaborao e comunicao
efetiva.
3. Compreender as tendncias sistemticas na natureza humana. Tal como, as pessoas
tendem a ser contrrias ao risco quando existe uma perda potencial, so indevidamente
otimistas em seus planos e projees, e preferem usar julgamentos intuitivos ao invs de
modelos quantitativos.
4. Engajamento para a qualidade. Uma mente focada sobre qualidade necessria para
descobrir erros e defeitos assim que possam ser endereados imediatamente.
5. Requisitos de usurios administradores porque mudaro ao longo do tempo.
Requisitos a base, definindo as caractersticas da qualidade de software.
Engenharia de Software 8
JEDI
TM
4. Tcnicas e Garantias de Qualidade de Software
Garantia de qualidade de Software um subconjunto da engenharia de software que assegura
que todos os produtos de trabalho sejam realizados, e que cumpram com as exigncias e padres
estabelecidos pelos usurios. Considera-se como uma das atividades mais importantes que
aplicada durante todo o processo do desenvolvimento do software. O objetivo detectar defeitos
antes do software ser entregue como um produto acabado para o usurio final. Isto abrange uma
aproximao eficaz da gerncia de qualidade, tecnologia de engenharia de software (mtodos e
ferramentas), tcnicas formais de reviso, vrias estratgias de teste, controle de documentao
de software e alteraes feitas, um procedimento para assegurar a conformidade com os padres
de desenvolvimento de software, e um mecanismo para mensur-los e document-los.
4.1. Qualidade de Software
Um software possui qualidade se ele estiver ajustado para uso, isto , se estiver trabalhando
corretamente. Para que ele trabalhe corretamente, ele deve estar em conformidade com os
requisitos funcionais e de performance (caractersticas externas dos usurios), padres
explicitamente documentados de desenvolvimento (padres de qualidade), e caractersticas
implcitas (caractersticas internas aos desenvolvedores) que so esperadas por todo
desenvolvimento profissional de software.
Trs pontos importantes enfatizados para definir a qualidade do software.
1. Requisitos de Software so a base para a qualidade do software. necessrio explicitar,
especificar e priorizar.
2. Padres definem um de critrios de desenvolvimento que iro mostrar a maneira com a qual
o software ser desenvolvido.
3. Caractersticas implcitas devero ser identificadas e documentadas; elas influenciam na
maneira de como o software ser desenvolvido assim como sua manutenibilidade.
4.2. Caractersticas para uma Boa Engenharia de Software
Para definir uma boa engenharia de software, d uma olhada nas caractersticas especficas que o
software apresenta. Algumas delas esto enumeradas abaixo:
Usabilidade. a caracterstica do software de apresentar facilidades entre a comunicao
dos usurios com o sistema.
Portabilidade. a capacidade do software ser executado em diferentes plataformas e
arquiteturas.
Reusabilidade. a habilidade do software de se transferir de um sistema para outro.
Manutenibilidade. a habilidade do software de se envolver e adaptar-se s alteraes em
um curto espao de tempo. caracterizado pela fcil atualizao e manuteno.
Dependncia. a caracterstica do software ser confivel e de segurana.
Eficincia. a capacidade do software utilizar os recursos com maior eficincia.
4.3. Atividades da Garantia de Qualidade de Software
Garantia de Qualidade de Software composta por uma variedade de atividades com o objetivo
de construir software com qualidade. Isto envolve dois grupos de desenvolvedores e a equipe de
SQA (Software Quality Assurance). A equipe de SQA tem responsabilidade em garantir
plenamente qualidade, supervisionar, manter, analisar e reportar defeitos. As atividades
envolvidas so as seguintes:
1. A equipe de SQA prepara o Plano de SQA. Isto se d durante a fase de planejamento de
projeto. Identificam-na:
Engenharia de Software 9
JEDI
TM
Avaliao a ser executada;
Auditorias e revises a serem executadas;
Padres que devem ser aplicados;
Procedimentos de erros reportados e monitorados;
Documentos que devem ser produzidos; e
Conjunto de respostas que se fizer necessrio.
2. A equipe de SQA participa na descrio do processo de desenvolvimento de software. O
time de desenvolvedores escolhe o processo de desenvolvimento e a equipe de SQA deve
verificar se ele se enquadra na poltica organizacional e nos padres de qualidade.
3. A equipe de SQA revisa as atividades de engenharia de software empregadas pelo time de
desenvolvedores para checar a conformidade com o processo de desenvolvimento de
software. Eles monitoram e seguem desvios do processo do desenvolvimento do software.
Documentam-no e asseguram-se de que as correes sejam feitas.
4. A equipe de SQA rev o trabalho para verificar se esto conforme o padro definido. Eles
monitoram e marcam defeitos e falhas encontrados em cada trabalho.
5. A equipe de SQA assegura-se que os desvios nas atividades de software e no processo de
produo estejam seguramente baseados na definio de procedimentos e padres de
operao.
6. A equipe de SQA envia desvios e desconformidades aos padres para os gerentes ou a
quem for de interesse.
4.4. Tcnicas Formais de Reviso
Produtos de trabalho so as sadas esperadas como resultado da execuo de tarefas no
processo de desenvolvimento de software. Esses resultados contribuem para o desenvolvimento
de software com qualidade. Conseqentemente, devem ser mensurados e verificados novamente
se vo ao encontro das exigncias e dos padres. As alteraes nos produtos de trabalho so
significativas; elas podem ser monitoradas e controladas. A tcnica de checar a qualidade dos
produtos de trabalho a tcnica formal de reviso. Formal Technical Reviews (FTR) so
executadas em vrios pontos do processo do desenvolvimento do software. Ela serve para
descobrir erros e defeitos que podem ser eliminados antes do software ser enviado para o usurio
final. Especificamente, seus objetivos so:
1. Descobrir erros em funes, na lgica ou na execuo para toda a representao do
software;
2. Verificar se o software sob a reviso encontra-se de acordo com os requisitos do usurio;
3. Assegurar-se que o software esteja de acordo com os padres definidos;
4. Conseguir que o software seja desenvolvido de uma maneira uniforme; e
5. Desenvolver projetos mais gerenciveis.
Um guia geral de conduo das tcnicas formais de reviso est listado abaixo.
Revisar o produto de trabalho e NO o desenvolvedor do produto de trabalho. O
objetivo da reviso e descobrir erros e defeitos para melhorar a qualidade do software. O
tom da reviso pode ser brando, porm construtivo.
Planejar e cumprir a agenda. Revises no devem durar mais de duas horas.
Minimizar os debates e discusses. inevitvel que os problemas sejam levantados e
isso no cause efeito nas pessoas. Lembre a todos que no hora de resolver os problemas
que sero apenas documentados, uma outra reunio deve ser agendada para resolv-los.
Indique reas de problema, mas no s tente resolv-las. Mencione e esclarea reas
de problema. Entretanto, no hora de resolver problemas, devero ser resolvidos em uma
outra reunio.
Tome nota. uma boa prtica tomar nota do que foi dito e suas prioridades para que elas
Engenharia de Software 10
JEDI
TM
possam ser vistas por outros revisores. Isto ajudar a esclarecer os defeitos e aes a serem
tomadas.
Mantenha o nmero dos participantes a um mnimo e insista em preparar-se para a
reviso. Escrever comentrios e observaes pelos revisores uma boa tcnica.
Fornea uma lista de verificao para o produto de trabalho que provvel ser
revista. A lista de reviso prov uma estrutura que conduza a reviso. Isto tambm ajuda
os revisores a manterem o foco na questo.
Programe as revises como parte do processo de desenvolvimento de software e
assegure-se de que os recursos sejam fornecidos para cada revisor. Preparao prev
interpretaes em uma reunio. Isto tambm ajuda os revisores a manterem o foco na
questo.
Sumrio da reviso. Verifica a eficcia do processo da reviso.
Duas tcnicas formais de reviso do produto de trabalho usadas na indstria so Fagan's
Inspection Method e Walkthroughs.
4.4.1. Mtodo de Inspeo de Fagan
Introduzido por Fagan em 1976 na IBM. Originalmente foi utilizado para verificar cdigos de
programas. Entretanto, pode ser estendido para incluir outros produtos de trabalho como tcnicas
de documentos, modelo de elementos, projetos de cdigos e dados etc. Isto gerenciado por um
moderador que responsvel por supervisionar a reviso. Isto requer uma equipe de inspetores
designados a verificar se as regras do produto de trabalho vo de encontro lista de interesse
preparada. mais formal que o walkthrough. A seguir esto descritas regras determinadas na
qual cada participante dever aderir:
As inspees so realizadas em um nmero de pontos no processo do planejamento do
projeto e do desenvolvimento dos sistemas.
Todas as classes com defeito so documentadas e os produtos do trabalho so inspecionados
no somente a nvel lgico, de especificaes ou de funes de erros.
A inspeo realizada por colegas em todos os nveis exceto o chefe.
As inspees so realizadas em uma lista prescrita das atividades.
As reunies de inspeo so limitadas a duas horas.
As inspees so conduzidas por um moderador treinado.
Inspetores so designados a especificar regras para aumentar a eficcia. As listas de
verificao dos questionrios a serem perguntados pelos inspetores so usadas para definir
tarefas e estimular a encontrar defeitos. Os materiais so inspecionados minuciosamente
para que seja encontrado o mximo nmero de possveis erros.
Estatsticas com os tipos de erros so vitais, so utilizadas para obter anlises de uma
maneira similar anlise financeira.
Conduzir inspees requer muitas atividades. Elas esto categorizadas a seguir:
Planejamento. O moderador deve se preparar para a inspeo. Decide quem sero os
inspetores e as regras que estes devem obedecer, quem e quando desempenharo seus
papis e distribuir a documentao necessria.
Uma rpida apresentao. 30 minutos de apresentao do projeto dos inspetores o
suficiente. Isto pode ser omitido se todos estiverem bem familiarizados com o projeto.
Preparando. Cada inspetor ter de 1 a 2 horas sozinho para inspecionar o produto de
trabalho. Ele ir executar as regras passadas a ele com base na documentao provida pelo
moderador. Ele ir tentar descobrir defeitos no produto de trabalho. Ele no dever reparar
defeitos ou criticar o desenvolvedor do produto de trabalho.
Realizando a reunio. Os participantes das reunies so inspetores, moderadores e
desenvolvedores do produto de trabalho. Os desenvolvedores do produto de trabalho esto
presentes para explicar o produto de trabalho, e responder s perguntas que os inspetores
fizerem. Nenhuma discusso se o defeito ou no real permitida. Uma lista de defeitos
deve ser produzida pelo moderador.
Engenharia de Software 11
JEDI
TM
Refazendo o produto de trabalho. A lista de defeitos deve ser atribuda a uma pessoa
para repar-la. Normalmente, esta o desenvolvedor do produto de trabalho.
Acompanhando os reajustes. O moderador assegura-se que os defeitos nos produtos de
trabalho sejam endereados e solucionados. Mais tarde este deve ser inspecionado por outro
inspetor.
Realizando uma reunio ocasional de anlise. Isto opcional, momento onde dada a
possibilidade aos inspetores de expressarem sua viso pessoal sobre erros e melhorias. A
nfase dada maneira que a inspeo foi feita.
4.4.2. Walkthrough
O walkthrough menos formal que a inspeo. Aqui, o produto de trabalho e sua documentao
correspondente so entregues para um time de revisores, normalmente em torno de 3 pessoas,
onde comentrios de sua exatido so apresentados. Ao contrrio da inspeo onde um o
moderador, o desenvolvedor do produto de trabalho coordena o walkthrough. Um escrivo
tambm deve estar presente para documentar a lista de aes. Uma lista de aes deve ser feita
a fim de melhorar a qualidade do produto final a qual inclui ajustes dos defeitos, resolues dos
problemas etc.
Alguns passos devem ser seguidos para obter sucesso no walkthrough. Eles esto listados abaixo:
Nenhum gerente deve estar presente.
Enfatizar que o walkthrough para deteco de erros e no para correo.
Manter o interesse do grupo.
Nenhuma contagem ou atribuio de nota.
Criticar o produto; no a pessoa.
Sempre documentar a lista de aes.
Conduzir o walkthrough, similar inspeo, requer muitas atividades. Elas esto categorizadas
como se segue:
Antes do walkthrough
O desenvolvedor do produto de trabalho agenda o walkthrough, preferivelmente, com um
dia de antecedncia ou dois no mximo.
Distribuir o material necessrio para o produto de trabalho dos revisores.
Pede-se especificamente que cada revisor traga pelo menos dois comentrios positivos do
walkthrough e um comentrio negativo sobre o produto do trabalho.
Durante o walkthrough
O desenvolvedor do produto de trabalho faz uma rpida apresentao do seu produto de
trabalho. Este passo pode ser ignorado caso os revisores conheam bem o produto de
trabalho.
Solicitar comentrios aos revisores. s vezes, problemas so levantados e apresentados,
mas no devem ser solucionados durante o walkthrough. Os problemas devero ser
includos em uma lista de aes.
Uma lista de aes deve ser produzida at o fim do walkthrough.
Aps o walkthrough
O desenvolvedor do produto de trabalho recebe a lista de aes.
Pede-se para enviar os estados das aes com o objetivo de resolver erros ou
discrepncias apresentadas na lista de aes.
Possivelmente, um outro walkthrough deve ser agendado.
Engenharia de Software 12
JEDI
TM
5. O Processo de Software
O processo de software prov uma estratgia que as equipes de desenvolvimento empregam
para construir software com qualidade. Ele escolhido baseado na maturidade do projeto e
aplicao, mtodos e ferramentas utilizadas e gerncia e produtos que so exigidos. Pressman
fornece uma representao grfica do processo de software. De acordo com ele, esta
representao fornece a estrutura que um plano compreensivo de desenvolvimento de software
pode estabelecer. Consiste em estrutura de atividades, conjunto de tarefas e atividades
guarda-chuva
3
.
Figura 2: Processo de Software Pressman
Estrutura de Atividades
Estas atividades so executadas por pessoas envolvidas no processo de desenvolvimento aplicado
a qualquer projeto de software independente do tamanho, composio da equipe ou
complexidade do problema. Tambm so conhecidos como fases do processo de desenvolvimento
de software.
Conjunto de Tarefas
Cada uma das atividades na estrutura do processo define um conjunto de tarefas. Estas tarefas
devem ter marcos, produtos que podem ser entregues ou produtos finais e pontos de garantia de
qualidade de software (Pontos de SQA). Eles so modificados e ajustados a uma caracterstica
especfica do projeto de software e dos requisitos de software.
Atividades Guarda-chuva
Estas so atividades que do suporte s atividades estruturais ao longo do progresso do projeto
de software como a gerncia de projeto, gerncia de configurao, gerncia de requisitos,
gerncia de riscos, reviso tcnica formal, etc.
5.1. Tipos de Modelos de Processo de Software
Existem vrios tipos de modelos de processo de software. Os mais comuns so discutidos nesta
seo.
Modelo Linear Seqencial
Tambm conhecido como modelo cascata ou ciclo de vida clssico. Este o primeiro modelo
formalizado. Outros modelos de processo so baseados em sua abordagem de desenvolvimento
3 Pressman, Software Engineering A Practitioner's Approach, p. 54-55
Engenharia de Software 13
Estrutura do Processo Comum
Atividades guarda-chuva
Estrut.de Atividades n
Estrut. de Atividades 2
Estrutura de Atividades 1
Cj.Tarefas 1:
Tarefas
Marcos
Entregveis
Pontos de SQA
Cj.Tarefas 1:
Tarefas
Marcos
Entregveis
Pontos de SQA
Conj. Tarefas 1:
Tarefas
Marcos
Entregveis
Pontos de SQA
JEDI
TM
de software. Ele sugere uma abordagem sistemtica e seqencial para o desenvolvimento de
software. Ele inicia pela anlise do sistema, progredindo para a anlise do software, projeto,
codificao, teste e manuteno. Ele prega que uma fase no pode iniciar enquanto a anterior no
seja finalizada. A Figura 3 mostra este tipo de modelo de processo de software.
Figura 3: Modelo Linear Seqencial
As vantagens deste modelo so:
o primeiro modelo de software formulado.
Fornece a base para outros modelos de processo de software.
As desvantagens deste modelo so:
Projetos de software reais dificilmente seguem restritamente um fluxo seqencial. De
fato, muito difcil decidir quando uma fase termina e a outra comea.
O envolvimento do usurio final s ocorre no incio (engenharia de requisitos) e no final
(operao e manuteno). Ele no mapeia o fato dos requisitos mudarem durante o
projeto de desenvolvimento de software.
s vezes os usurios finais tm dificuldades de estabelecer todos os requisitos no incio.
Logo, isto atrasa o desenvolvimento do software.
Modelo de Prototipao
Para auxiliar o entendimento dos requisitos dos usurios, prottipos so construdos. Prottipos
so softwares desenvolvidos parcialmente para permitir aos usurios e desenvolvedores
examinarem caractersticas do sistema proposto e decidir se devem ser includos no produto final.
Esta abordagem mais bem adaptada nas seguintes situaes:
Os clientes definem um conjunto de objetivos gerais para o software, mas no
identificam detalhes de entrada, processamento ou requisitos de sada.
O desenvolvedor no tem certeza da eficincia do algoritmo, da adaptabilidade da
tecnologia ou a forma que a interao homem-computador deve ser.
A Figura 4 mostra este modelo de processo.
Engenharia de Software 14
Engenharia de
Requisitos
Engenharia
de Projetos
Codificao
Testes
Operao
e
Manuteno
JEDI
TM
Figura 4: Modelo de Prototipao
A vantagem deste modelo de processo :
Os usurios tm participao ativa na definio dos requisitos de interao homem-
computador do sistema. Vem a aparncia atual do software.
As desvantagens deste modelo de processo so:
Os clientes podem erroneamente aceitar o prottipo como uma verso funcional. Isto
compromete a qualidade do software porque outros requisitos de software no so alvos
de manuteno.
Os desenvolvedores ficam tentados a implementar um prottipo funcional sem pensar
em futuras expanses ou manutenes.
Modelo de Desenvolvimento Rpido de Aplicaes (RAD)
Este um processo de desenvolvimento de software linear seqencial que enfatiza um ciclo de
desenvolvimento extremamente curto. Baseia-se em uma abordagem de construo modular.
melhor utilizado em projetos de software onde os requisitos j esto bem entendidos, o escopo do
projeto j est bem definido e uma grande carteira com recursos disponveis. Todos esperam
comprometer-se com a abordagem de desenvolvimento rpido.
Neste modelo de processo, o projeto de software definido baseado na decomposio funcional
do software. Parties funcionais so associadas a diferentes equipes e so desenvolvidas em
paralelo. A Figura 5 mostra este modelo de processo.
Figura 5: Desenvolvimento Rpido de Aplicaes
Engenharia de Software 15
Entrevista dos
Clientes
Desenvolvedores
constroem ou
revisam prottipos
Clientes testam
o prottipo
Engenharia
de
Requisitos
Engenharia
de Projetos
Codificao
Testes
Fim-Turno
Partio Funcional
1- Equipe
Engenharia
de
Requisitos
Engenharia
de Projetos
Codificao
Testes
Fim-Turno
Partio Funcional
2 - Equipe
Engenharia
de
Requisitos
Engenharia
de Projetos
Codificao
Testes
Fim-Turno
Partio Funcional
3 - Equipe
60 a 90 Dias
JEDI
TM
A vantagem deste modelo :
Um sistema totalmente funcional criado em um curto espao de tempo.
As desvantagens deste modelo so:
Para um projeto de larga escala este processo requer um nmero suficiente de
desenvolvedores para formar o nmero certo de equipes.
Desenvolvedores e clientes devem se comprometer com as atividades relmpagos
necessrias para desenvolver um software em um curto espao de tempo.
No um bom modelo de processo para sistemas que no so modularizveis.
No um bom modelo de processo para sistemas que requerem alta performance.
No um bom modelo de processo para sistemas que fazem uso de novas tecnologias
ou tm alto grau de interoperabilidade com programas j existentes como os sistemas
legados.
Modelo de Processo Evolucionrio
Este modelo de processo reconhece que um software envolve mais de um perodo de tempo. Ele
permite o desenvolvimento de uma verso mais crescentemente complexa de software. A
abordagem naturalmente iterativa. Alguns modelos de processo evolucionrio especficos so:
Modelo Incremental, Modelo Espiral e Modelo Baseado em Montagem de Componentes.
Modelo Incremental
Este modelo de processo combina os elementos do modelo linear seqencial com a interatividade
do modelo de prototipao. As seqncias lineares so definidas de maneira que cada seqncia
produza um incremento de software. Diferente da prototipao, o incremento um produto
operacional. A Figura 6 mostra este modelo de processo.
Figura 6: Modelo de Processo Incremental
Modelo Espiral
Foi originalmente proposto por Boehm. um modelo de processo de software evolucionrio
Engenharia de Software 16
Engenharia
de
Requisitos
Engenharia
de Projeto
Codificao
Testes
Entrega do
Primeiro
Incremento
Primeiro
Incremento
Engenharia
de
Requisitos
Engenharia
de Projeto
Codificao
Testes
Fim-Turno
Segundo
Incremento
Engenharia
de
Requisitos
Engenharia
de Projeto
Codificao
Testes
Fim-Turno
Terceiro
Incremento
Primeiro
Incremento de SW
Segundo
Incremento
de SW
Primeiro
Incremento de SW
Terceiro
Incremento
de SW
Primeiro
Incremento de SW
Segundo
Incremento
de SW
JEDI
TM
acoplado naturalidade iterativa da prototipao com o controle e os aspectos sistemticos do
modelo linear seqencial. Ele disponibiliza potencial para desenvolvimento rpido de verses
incrementais do software. Uma importante caracterstica deste modelo que sua anlise de risco
faz parte da sua estrutura de atividades. Porm, isto requer experincia em estimativa de riscos.
A Figura 7 mostra um exemplo do modelo espiral.
Figura 7: Modelo Espiral
Modelo de Montagem Baseada em Componentes
similar ao Modelo de Processo Espiral. No entanto, este usa a tecnologia de objetos onde a
nfase a criao das classes que encapsulam dados e mtodos utilizados para manipular os
dados. A reusabilidade uma das caractersticas de qualidade que sempre checado durante o
desenvolvimento do software. A Figura 8 mostra o Modelo de Montagem Baseada em
Componentes.
Figura 8: Modelo de Montagem Baseada em Componentes
Modelo de Desenvolvimento Concorrente
Engenharia de Software 17
Anlise de risco
Planejamento
Comunicao
Anlise & Projeto
Codificao &
Distribuio
Avaliao
A B C D
A. Projeto Inicial do Software
B. Manuteno do Novo Software
C. Melhoramento do Software
D. Desenvolvimento de outro sistema inter-
relacionado
Anlise de
Risco
Planejamento
Comunicao
Anlise OO &
Projeto
Codificao &
Distribuio
Avaliao
A B C D
A. Projeto Inicial do Software
B. Manuteno do Novo Software
C. Melhoramento do Software
D. Desenvolvimento de outro sistema inter-relacionado
Determinar
Classes
Candidatas
Verificar Classes
na Biblioteca
Utilize as
Classes
Construir
Nova Classe
Colocar Novas
Classes na
Biblioteca
Construir a
ensima Iterao
do Software
JEDI
TM
O Modelo de Desenvolvimento Concorrente tambm conhecido como engenharia concorrente.
Ele utiliza os diagramas de estado para representar a relao de concorrncia entre tarefas
associadas na estrutura de atividades. Ele representado esquematicamente por uma srie de
tarefas tcnicas maiores e estados associados. A necessidade do usurio, a deciso gerencial e a
reviso de resultados dirigem a progresso geral do desenvolvimento. A Figura 9 mostra o modelo
de desenvolvimento concorrente.
Figura 9: Modelo de Desenvolvimento Concorrente
Mtodos Formais
uma abordagem da engenharia de software que incorpora um conjunto de atividades guiadas
por uma especificao matemtica do software. Eles fornecem um mecanismo para remover
vrios problemas que dificultariam o uso de outros paradigmas de engenharia de software. Serve
como um meio de verificar, descobrir e corrigir erros que de outra forma no seriam detectados.
5.2. Fatores que Afetam a Escolha do Modelo de Processo
Tipo do Projeto
Mtodos e Ferramentas a serem utilizadas
Requisitos e Pessoas-Chaves do Negcio
Senso Comum e Julgamento
Engenharia de Software 18
Incio
Desenvolver
Modelo
Examinar
Modelo
Entrar com
Novas Linhas
Bases
Revisar
Modelo
Aguardar
Mudanas
Fim
Atividades
de Anlise
JEDI
TM
6. Entendendo Sistemas
O projeto de software que necessita ser desenvolvido revolve em torno dos sistemas. Os sistemas
consistem em um grupo de entidades ou componentes, Juntos interagem para dar forma aos
inter-relacionamentos especficos, organizados por meio da estrutura, e trabalhando para
conseguir um objetivo comum. Compreender sistemas fornece um contexto para todo o projeto
com a definio dos limites dos projetos. Surge a pergunta, "O que includo no projeto? O que
no ?" Em definio de limites do sistema, um Engenheiro de Software descobre o seguinte:
As entidades ou o grupo das entidades que so relacionadas e organizadas de alguma
maneira dentro do sistema fornecem a entrada, realizam atividades ou recebem a
sada;
Atividades ou aes que devem ser executadas pelas entidades ou pelo grupo das
entidades a fim conseguir a finalidade do sistema;
Uma lista de entrada; e
Uma lista de sada.
Como exemplo, a Figura 10 mostra os limites do sistema do estudo de caso. Mostra elementos
deste sistema com o uso do diagrama do contexto.
Figura 10: Limites do sistema de aplicao da sociedade do clube
As entidades que so envolvidas neste sistema so os candidatos, a equipe de funcionrios do
clube e o treinador. So representadas como caixas retangulares. So relacionadas umas com as
outras executando determinadas atividades dentro deste sistema. As principais atividades
executadas so o envio dos formulrios de aplicao, programar as simulaes de sadas e a
atribuio do pretendente a um grupo. So representados por um crculo no meio que define a
funcionalidade da informao mantendo a sociedade do clube. Para executar estas aes, uma
lista das entradas necessria. Especificamente, formulrios de aplicao e a programao das
simulaes de sadas. So representados por uma seta com o nome dos dados que esto sendo
passados. A ponta da seta indica o fluxo dos dados. Os resultados mais importantes que se
espera deste sistema so os relatrios da sociedade e as listas de grupos. Outra vez, so
representados por uma seta com o nome dos dados que esto sendo passados. A ponta da seta
indica o fluxo dos dados. O objetivo deste sistema segurar a aplicao da sociedade do clube.
Princpios Gerais de Sistemas
Alguns princpios gerais dos sistemas so discutidos abaixo. Isto ajudar ao Engenheiro de
Software a estudar o sistema onde o projeto do software revolve.
Mais especializado um sistema, menos capaz de adaptar-se a circunstncias
diferentes. As mudanas teriam um impacto grande no desenvolvimento de tais sistemas.
Cada um deve ser cuidadosamente certificado que no h nenhuma mudana dramtica no
ambiente ou nas exigncias quando o software est sendo desenvolvido. As partes
interessadas e os colaboradores devem estar cientes dos riscos e dos custos das mudanas
Engenharia de Software 19
ATIVIDADES:
submeter aplicao
agendar simulaes de sada
associar candidatos a grupo
Candidato
Equipe do
Clube
Treinador
Equipe do
Clube
ENTIDADES ENTIDADES
formulrio de
requerimento
Agendamento
das
simulaes de
sada
relatrio de
scios
lista de
grupos
ENTRADAS SADAS
JEDI
TM
durante o desenvolvimento do software.
Maior o sistema , mais os recursos devem ser devotados sua manuteno diria.
Como um exemplo, o custo de manter um mainframe muito caro comparado a manter
diversos computadores pessoais.
Os sistemas so sempre parte de sistemas maiores, e podem sempre ser divididos
em sistemas menores. Este o princpio o mais importante que um Engenheiro de
Software deve compreender. Porque os sistemas so compostos da verso menor do
subsistema e do vice, os sistemas de software podem ser desenvolvidos em uma maneira
modular. importante determinar os limites dos sistemas e de suas interaes de modo que
o impacto de seu desenvolvimento seja mnimo e possa ser controlado.
Componentes de um Sistema Automatizado
H dois tipos de sistemas, a saber, sistemas sintticos e sistemas automatizados. Os sistemas
sintticos so considerados tambm sistemas manuais. No so perfeitos. Tero sempre reas
para aumentar a exatido e melhorias. Estas reas para a exatido e as melhorias podem ser
direcionadas por sistemas automatizados.
Os sistemas automatizados so exemplos dos sistemas. Consiste em componentes que suporta a
operao de um sistema domnio-especfico. No geral, consiste no seguinte:
1. Hardware. Esse componente o dispositivo fsico.
2. Software. Esse componente o programa executado pela mquina.
3. Pessoal. Esse componente responsvel pelo uso do hardware e software. Provem dados
como entrada, e interpretam a sada (informao) para as decises dirias.
4. Processos. Este componente representa a poltica e os procedimentos que governam a
operao do sistema automatizado.
5. Dados e Informao. Este componente fornece a entrada (dados) e a sada (informao).
6. Conectividade. Este componente permite a conexo de um sistema computadorizado com
um outro sistema. Conhecido tambm como componente de rede.
A Figura 11 mostra a relao dos cinco primeiros componentes.
Figura 11: Componentes de um Sistema Automatizado
A Figura 12 representa uma ilustrao de um domnio-especfico da aplicao de um sistema
automatizado. Demonstra o sistema automatizado que processa a aplicao da sociedade do
clube.
Engenharia de Software 20
1
COMPUTADOR
HARDWARE
2
COMPUTADOR
SOFTWARE
4
PROCEDIMENTO
MANUAL
Entrada
4
PROCEDIMENTO
COMPUTADORIZAD
O
Processando
4
PROCEDIMENTO
MANUAL
Sada
3
PESSOAL
3
PESSOAL
Entrar Dados
Monitorar Atividades
Ler Processos Manuais
Revisar nformaes
Tomar Decises
Mudar Regras Processuais 5
DADOS
5
INFORMAO
JEDI
TM
Figura 12: Sistema computadorizado da aplicao da sociedade do clube
A informao da aplicao da sociedade do clube incorporada ao sistema. O pretendente
programado para a simulao de tentativa de sada. Esta programao recuperada do
armazenamento. Uma vez que um pretendente atribudo a um grupo, esta informao est
incorporada no sistema de modo que o relatrio da lista do grupo seja produzido.
Engenharia de Software 21
FASE ENTRADA
FASE
PROCESSAMENTO
FASE DE SADA
FASE DE ApIicaes da Programao das Listas do Grupo
ARMAZENAMENTO Socie dade simulaes de sada
Sociedade CIube
ApIicao
Listas do Grupo
ReIatrios para a
Sociendade do
CIube
JEDI
TM
7. Entendendo as Pessoas no Esforo de
Desenvolvimento
Para ajudar na promoo da idia comum de qualidade na equipe de desenvolvimento, devemos
entender as pessoas envolvidas no processo, particularmente, seus interesses a respeito do
sistema e o software que precisa ser desenvolvido. Nesta seo, h dois grupos principais
envolvidos no esforo de desenvolvimento de software, especificamente, usurios finais e equipe
de desenvolvimento.
7.1. Usurios finais
Usurios finais so pessoas que iro utilizar o produto final. Muitos dos requisitos viro deste
grupo. Eles podem ser divididos em dois grupos de acordo com o envolvimento dentro da
organizao e desenvolvimento, a saber: aqueles envolvidos diretamente e aqueles envolvidos
indiretamente.
Aqueles que esto diretamente envolvidos
A Tabela 1 mostra a categorizao dos usurios finais de acordo com as funes que eles
executam no sistema.
Operacionais Supervisores Executivos
Executam as funes
operacionais do sistema.
Executam aes de superviso sobre
as operaes dirias do sistema. Eles
so em geral avaliados e motivados
pela performance de seus
oramentos.
Normalmente possuem iniciativa
e servem como financiadores do
projeto de desenvolvimento do
sistema.
So normalmente mais
concentrados com o componente
de interface humana do sistema:
Que tipo de teclado iro
utilizar?
Que tipo de tela de
apresentao o sistema ter?
Haver muito brilho e haver
caracteres de fcil leitura?
So normalmente mais concentrados
na eficincia operacional das funes
que precisam ser executadas como a
quantidade de sadas em menor
tempo.
So menos concentrados nas
operaes do dia-a-dia. So
mais concentrados nas
estratgias de lucros e prejuzos
a longo prazo.
Tm uma viso local do sistema. Tambm tendem a ter a mesma viso
local e fsica do sistema similar aos
usurios operacionais, mas com
ateno voltada a performance.
Esto mais interessados na viso
global do sistema.
Tendem a pensar no sistema em
termos fsicos.
So os que tm mais contato com os
engenheiros de software.
Geralmente trabalham com
modelos abstratos do sistema
assim como termos fsicos.
Possuem maiores interesse em
resultados.
Tabela 1: Categorias de Trabalho
Guias Gerais e os Usurios Finais
O mais alto nvel de gerncia provavelmente pouco se importa com a tecnologia de
computadores. Seria melhor perguntar-lhes sobre o resultado global e performance que os
sistemas fornecem. So bons candidatos para entrevistas a respeito de leiautes de relatrios
e design de cdigo.
Os objetivos e prioridades da gerncia podem entrar em conflito com os dos supervisores e
usurios operacionais. Isto pode ser percebido baseado nos diferentes nveis de
preocupaes. Como engenheiro de software, tenta-se descobrir reas comuns. Mais sobre o
assunto pode ser visto no captulo 3 - Engenharia de Requisitos.
Engenharia de Software 22
JEDI
TM
Gerentes podem no fornecer recursos, fundos ou tempo que usurios precisam para
construir um sistema efetivo. Restries financeiras e de recurso iro ocorrer. importante
priorizar os requisitos. Mais sobre isto pode ser visto no captulo 3 - Engenharia de
Requisitos.
Aqueles que esto indiretamente envolvidos
Freqentemente, este grupo inclui auditores, portadores comuns e grupo de garantia de
qualidade. O objetivo geral deste grupo certificar que o sistema est sendo desenvolvido de
acordo com uma variedade de definies como:
Padres contbeis desenvolvidas pelas operaes de contas da organizao ou firma.
Padres desenvolvidos por outros departamentos dentro da organizao ou pelo cliente
ou pelo usurio que ir herdar o sistema
Vrios padres impostos pelas agncias governamentais reguladoras.
Alguns possveis problemas que podemos encontrar com este grupo. Como engenheiro de
software, manter ateno sobre eles e mape-los em conformidade.
Eles no se envolvem no projeto at que se atinja o fim, em particular, o grupo de
garantia de qualidade. importante que eles envolvam-se em todas as atividades que
se exija sua experincia e opinio.
Eles fornecem notao necessria e forma do documento. Eles podem precisar de
definio para apresentao e documentao do sistema.
Eles esto mais interessados em substncia do que em formulrios.
7.2. Equipe de Desenvolvimento
A equipe de desenvolvimento responsvel pela construo do software que ir dar suporte ao
sistema de domnio-especfico. Consistem em: analista de sistemas, projetista, programadores e
testadores.
Analista de Sistemas
Sua responsabilidade entender o sistema. Dentro do sistema, ele identifica o que o cliente quer
e documenta e prioriza os requisitos. Isto envolve detalhamento do sistema para determinar
requisitos especficos que sero a base do projeto de software.
Projetista
Seu trabalho transformar uma tecnologia livre de arquitetura em uma estrutura interna para
que os programadores possam trabalhar. Normalmente, o analista de sistema e o projetista so a
mesma pessoa, mas isto diferenciado pelo foco nas funes e habilidades requeridas.
Programadores
Baseados no projeto do sistema, os programadores escrevem o cdigo do software utilizando uma
linguagem de programao.
Testadores
Para cada produto funcional, deve-se realizar uma reviso de modo a encontrar: falhas ou erros.
Isto sustenta a cultura de qualidade necessria ao desenvolvimento de software com qualidade.
Isto garante que o produto funcional ir de encontro com os requisitos e padres definidos.
Engenharia de Software 23
JEDI
TM
8. Documentao no Esforo de Desenvolvimento
8.1. O que documentao?
um conjunto de documentos ou informaes do produto que descrevem o sistema. Cada
documento desenhado para executar uma funo especfica, como:
REFERNCIA, como por exemplo, especificaes tcnicas ou funcionais.
INSTRUCIONAL, como por exemplo, tutoriais, demonstraes ou prottipos.
MOTIVACIONAL, como por exemplo, brochuras, demonstraes ou prottipos.
H vrios tipos de documentao e informaes funcionais do produto. Alguns so citados abaixo:
Caractersticas e Funes do Sistema
Sumrio Gerencial e do Usurio
Manual do Usurio
Manual de Administrao do Sistema
Vdeo
Multimdia
Tutoriais
Demonstraes
Guia de Referncia
Guia de Referncia Rpida
Referncias Tcnicas
Arquivos de Manuteno do Sistema
Modelos de Teste do Sistema
Procedimentos de Converso
Manual de Operaes/Operador
Help On-Line
Wall Charts
Layout de Teclado ou Templates
Jornais
Bons documentos no geram sistemas complicados. No entanto, eles podem ajudar de outra
forma. A tabela seguinte mostra como a documentao ajuda no processo de desenvolvimento de
software.
Se o manual do usurio for
desenvolvido durante....
Ento, o manual pode...
A definio do produto Clarear procedimentos e regras
Identificar elementos no amigveis
Aumentar as chances de satisfao do cliente
O projeto e codificao Clarear problemas e erros
Identificar causas de inconsistncias
Forar o projetista a tomar decises mais cedo
A distribuio e uso do sistema Ajudar os usurios a se adaptarem ao sistema
Alertar sobre problemas no sistema
Negar responsabilidades
Tabela 2: Significncia dos Documentos
Existem dois principais propsitos da documentao. Especificamente, eles:
Fornecem um argumento racional e permanente para a estrutura do sistema ou
comportamento atravs dos manuais de referncia, guia do usurio e documentos de
arquitetura do sistema.
Engenharia de Software 24
JEDI
TM
Servem como documentos transitrios que so parte de uma infra-estrutura envolvida em
uma execuo de um projeto real como: cenrios, documentao do projeto interno,
relatrio de reunies e problemas.
8.2. Critrios para Medio da Usabilidade de Documentos
Um documento til aumenta o entendimento do sistema solicitado e o atual comportamento e
estrutura. Serve como comunicao entre as verses arquiteturais do sistema. Fornece uma
descrio de detalhes que no pode ser diretamente inferida a partir do prprio software ou a
partir dos produtos funcionais. Alguns critrios para medio da usabilidade dos documentos
esto listados abaixo:
1. Disponibilidade. Usurios devem saber da existncia dos documentos. Devem estar
presentes no momento e local quando for necessrio.
2. Adequao. Devem ser adequados s tarefas e interesses do usurio. Devem ser precisos e
completos. Documentos relacionados devem estar localizados em um manual ou livro.
3. Acessibilidade. Devem estar em folhas ofcio (8.5in x 11in) para fcil manuseio,
armazenamento e recuperao. Deve ser fcil encontrar informaes que o usurio deseja.
Cada item da documentao deve ter um nico nome para referncia e referncia cruzada,
um propsito ou objetivo e um usurio alvo (a quem se destina o documento).
Encaminhamentos para outros manuais e livros devero ser evitados.
4. Legibilidade. Devem ser compreensveis sem explicaes adicionais. No devem possuir
abreviaes. Se for necessrio, devem vir acompanhados de legenda. Devem ser escritos
com fluncia e em estilo e formatao de fcil leitura.
8.3. Importncia dos Documentos e Manuais
Os documentos e manuais so importantes, pois so utilizados:
Para diminuir custos. Com bons manuais, necessitam-se menos de treinamento, suporte e
manuteno do sistema.
Como ferramentas de venda e marketing. Bons manuais diferenciam seus produtos - um
pobre manual significa um pobre produto - especialmente para produtos de software "fora
de prateleira.
Como entregveis tangveis. Gerenciamento e usurios sabem pouco sobre jarges da
computao, programas e procedimentos, mas podem encontrar isso no manual do usurio.
Como obrigaes contratuais.
Como coberturas de segurana. No caso de falta de pessoas, manuais e documentos tcnicos
servem como backup escrito.
Como auxlio a teste e implementao. importante incluir os seguintes itens como parte do
manual do usurio - modelos e scripts de teste do sistema, procedimentos burocrticos e
automatizados, treinamentos prticos para novos usurios e auxlio a projeto.
Para comparar sistemas antigos e novos.
Engenharia de Software 25
JEDI
TM
9. Exerccios
9.1. Especificao de escopo
1. Modele o escopo do Sistema de Informaes Tcnicas. Utilize a Figura 10 como guia.
2. Modele o escopo de um Sistema de Manuteno de Equipes e Times. Utilize a Figura 10 como
guia.
9.2. Praticando o Walkthrough
1. Revise o escopo do modelo do Sistema de Informaes Tcnicas atravs de um walkthrough.
Prepare uma lista de aes.
2. Revise o escopo do modelo do Sistema de Manuteno de Equipes & Times atravs de um
walkthrough. Prepare uma lista de aes.
9.3. Trabalho sobre Projeto
O objetivo do trabalho sobre projeto reforar o conhecimento e habilidade adquirida nesta lio.
Particularmente, so:
1. Definio de Escopo do Sistema
2. Criao de Modelo de Escopo de Sistema
3. Execuo de Walkthrough
PRODUTOS:
1. Modelo de Escopo do Sistema
2. Lista de Aes
Engenharia de Software 26
JEDI
TM
Parceiros que tornaram JEDI
TM
possvel
Instituto CTS
Patrocinador do DFJUG.
Sun Microsystems
Fornecimento de servidor de dados para o armazenamento dos vdeo-aulas.
Java Research and Development Center da Universidade das Filipinas
Criador da Iniciativa JEDI
TM
.
DFJUG
Detentor dos direitos do JEDI
TM
nos pases de lngua portuguesa.
Banco do Brasil
Disponibilizao de seus telecentros para abrigar e difundir a Iniciativa JEDI
TM
.
Politec
Suporte e apoio financeiro e logstico a todo o processo.
Borland
Apoio internacional para que possamos alcanar os outros pases de lngua
portuguesa.
Instituto Gaudium/CNBB
Fornecimento da sua infra-estrutura de hardware de seus servidores para que os
milhares de alunos possam acessar o material do curso simultaneamente.
Engenharia de Software 27