[Seminário] Metodologias Ageis

Metodologia

É uma abordagem disciplinada para o desenvolvimento de software com objetivo de tornar o processo mais previsível e eficiente.
Exemplos de Metodologia Ágeis

Extreme Programming (XP)
Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.
Scrum
O Scrum é uma metodologia de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Apesar de a palavra não ser um acrônimo, algumas empresas que implementam o processo a soletram com letras maiúsculas como SCRUM. Isto pode ser devido aos primeiros artigos de Ken Schwaber, que capitalizava SCRUM no título.
Feature Driven Development (FDD)
A FDD nasceu num projeto em Cingapura, entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por Jeff De Luca, um gerente de projetos australiano.
Dynamic Systems Development Method (DSDM)
Predefinição:Software development process Dynamic Systems Development Method, ou Metodologia de Desenvolvimento de Sistemas Dinâmicos (em português), é uma metodologia de Desenvolvimento de Software originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD). DSDM é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário.
Open Source Software Development
Desenvolvimento de software de fonte aberta é o processo pelo qual open source software (software ou similar, cujo código fonte está disponível ao público) é desenvolvido. Estes são os produtos de software "disponível com seu código fonte e sob uma licença de código aberto para estudar, mudar e melhorar a sua concepção ".
Rational Unified Process


O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.
O processo RUP não pode ser classificado como ágil. Vide processo AUP, pois trata-se de uma simplicação do RUP.


Origem das Metodologias Ágeis
• No ano de 2001 um grupo de profissionais reuniu-se para delinear os valores e princípios que permitiriam às equipes de desenvolvimento produzir rapidamente e responder ás mudanças.
• Eles chamaram a si mesmos de Aliança Ágil.
• O Manifesto Ágil é considerado oficialmente como inicio do movimento ágil.

Princípios das Metodologias Ágeis
Nós seguimos estes princípios:Nossa maior prioridade é satisfazer o cliente
através da entrega contínua e adiantada
de software com valor agregado.
Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando,
de poucas semanas a poucos meses,
com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente.
Contínua atenção à excelência técnica e bom design
aumenta a agilidade.
Simplicidade--a arte de maximizar a quantidade de
trabalho não realizado--é essencial.
As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

Aplicabilidade dos métodos ágeis
Fatores chave:
A cultura da organização deve apoiar a negociação.As pessoas devem ser confiantes.A organização deve promover as decisões que os desenvolvedores tomam.A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros

A aplicabilidade do desenvolvimento ágil para os seguinte cenários é ainda uma questão aberta:
• Esforços de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratégias para maiores escalas tenham sido descritas
• Esforços de desenvolvimento distribuído (equipes não co-alocadas).
• Esforços críticos de missão e vida.
• Companhias com uma cultura de comando e controle.

Ambiente ideal para o desenvolvimento ágil:
• Baixa criticidade
• Desenvolvedores sênior
• Mudanças freqüente de requisitos
• Pequeno número de desenvolvedores
• Cultura que tem sucesso no caos.
Pontos negativos
• Falta de estrutura e documentação necessárias
• Somente trabalhar com desenvolvedores de nível sênior
• Incorpora de forma insuficiente o projeto de software
• Requer a adoção de muita mudança cultural
• Poder levar a maiores dificuldades nas negociações contratuais


Casos de implementação das metodologias
Dados da pesquisa conduzida pela VersionOne apoiada pela Agile Alliance apontam:
O desenvolvimento ágil tem garantido um significante retorno sobre o investimento para as organizações que a adota.
Aumento da produtividade e da qualidade do software, aliado a capacidade de gerenciar requisitos em constante variação. É o grande motivador da adoção de uma metodologia ágil de desenvolvimento.

No inicio do movimento a principal barreia de implementação era a falta de apoio por parte das gerencias e da organização como um todo.
Atualmente, a falta de profissionais qualificados para o desenvolvimento ágil e a resistência dos próprios desenvolvedores à mudança são apontados como os principais fatores.


Previsões futuras para os Métodos Ágeis

Pode-se dizer que o desenvolvimento ágil está em um momento de inflexão, passando a ser adotado por um numero crescente de empresas. Com isso, um numero maior de equipes pode passar a quantificar seus resultados
Espera-se , para um futuro próximo, que informações mais consistentes, relativas à adoção das metodologias sejam levantadas e apresentadas à comunidade de desenvolvimento.


Conclusão

A escolha da metodologia mais adequada para o desenvolvimento de software em uma organização, levando em consideração os inúmeros fatores envolvidos, não é uma tarefa trivial. Por outro lado, é um fator preponderante para o sucesso da organização.
Embora um bom processo não possa garantir o sucesso de um projeto, certamente a adoção de um processo inadequado pode comprometê-lo.
O movimento ágil ainda deve ser classificado como uma inovação, embora alguns dados já apontem para um novo cenário, no qual o desenvolvimento ágil está em um momento de inflexão, passando a ser defendido também na esfera gerencial das organizações.
Uma deficiência importante é a ausência de dados que possam ser usados para avaliar, quantitativamente, a presença das diversas metodologias ágeis no mercado de desenvolvimento de software, bem como se adaptações que se fazem necessárias e o graus de satisfação de seus usuários.
Essa ausência é ainda mais sentida quando se procuram por dados referentes ao mercado nacional.

Metodologias Ágeis
ALUNOS: Bruno Cesar Bosso R.A 1801284739
Vanessa Sena de Holanda RA 1804297868

[Seminário] Métricas de Eng° de Software

“Não se pode gerenciar o que não se pode medir”.

[Tom De Marco]

“Se você não sabe para onde você quer ir, qualquer caminho você pode seguir. Se você não sabe onde você está, um mapa não vai ajudar!”.

[Roger Pressman]

O que são métricas de software?

· Uma métrica é a medição de um atributo (propriedades ou características ) de uma determinada entidade (produto, processo ou recursos). Exemplos:

· Tamanho do produto de software (ex: Número de Linhas de código)

· Número de pessoas necessárias para implementar um caso de uso

· Número de defeitos encontrados por fase de desenvolvimento

· Esforço para a realização de uma tarefa

· Tempo para a realização de uma tarefa

· Custo para a realização de uma tarefa

· Grau de satisfação do cliente (ex: adequação do produto ao propósito, conformidade do produto com a especificação)

Por que medir software?

· Entender e aperfeiçoar o processo de desenvolvimento

· Melhorar a gerência de projetos e o relacionamento com clientes

· Reduzir frustrações e pressões de cronograma

· Gerenciar contratos de software

· Indicar a qualidade de um produto de software

· Avaliar a produtividade do processo

· Avaliar os benefícios (em termos de produtividade e qualidade) de novos métodos e ferramentas de engenharia de software

· Avaliar retorno de investimento

Propriedades desejáveis de uma métrica:

· Facilmente calculada, entendida e testada

· Passível de estudos estatísticos

· Expressa em alguma unidade

· Obtida o mais cedo possível no ciclo de vida do software

· Passível de automação

· Repetível e independente do observador

· Sugere uma estratégia de melhoria

Em resumo...

· Uma métrica deve ser:

· Válida: quantifica o que queremos medir

· Confiável: produz os mesmos resultados dadas as mesmas condições

· Prática: barata, fácil de computar e fácil de interpretar

· Dois contextos para medição de software

· Processo: ex. produtividade

· Produto: ex. qualidade

Categorização de Métricas:

· Métricas diretas (fundamentais ou básicas)

Medida realizada em termos de atributos observados

(usualmente determinada pela contagem)

Ex.: custo, esforço, no. linhas de código, capacidade de memória, no. páginas, no. diagramas, etc.

· Métricas indiretas (derivadas)

Medidas obtidas a partir de outras métricas

Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção

· Métricas orientadas a tamanho

São medidas diretas do tamanho dos artefatos de software associados ao processo por meio do qual o software é desenvolvido.

Ex.: esforço, custo, no. KLOC, no. páginas de documentação, no. Erros

· Métricas orientadas por função

Consiste em um método para medição de software do ponto de vista do usuário, determinando de forma consistente o tamanho e a complexidade de um software

· Métricas de produtividade

Concentram-se na saída do processo de engenharia de software.

Ex.: no. de casos de uso/iteração.

· Métricas de qualidade

Oferecem uma indicação de quanto o software se adeqüa às exigências implícitas e explícitas do cliente.

Ex.: erros/fase

· Métricas técnicas

Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido.

Ex.: complexidade lógica e grau de manutenibilidade

Conclusão

As atividades de medição devem ser guiadas por objetivos.Plano de Métricas detalham como criar programas de medição para atender a objetivos técnicos específicos.Tendências recentes: evolução de métricas ou modelos específicos para amplos programas organizacionais de métricas

Referencias:

1. Chou, Tim. The Hidden Cost of Software. Maio 29, 2003.

2. Negulescu, Radu. Software Engineering McGill University, 2002.

3. Métricas de Software http://www.internext.com.br/mssa/medidas.html

4. Haufe, Maria Isabel. Produtividade no Desenvolvimento de Software.

5. Métricas e Estimativas de Software – O início de um rally de regularidade.

6. Pressman, Roger. S. Engenharia de Software. Makron Books, 1995.

Thiago Cambiaghi dos Santos - 0850334

Marcelo Machado Gomes – 1801271201

[Aula] Processos de Desenvolvimento de Software – Clássicos

Hello, everybody!

   Na aula desta semana, revisamos o conceito de processo de software e os modelos de processos através de uma dinâmica em grupo. Nesta dinâmica percebemos que se não temos nenhum processo, ou seja, o caos total, a produtividade e a qualidade do nosso produto era prejudicada. Quando nos organizamos e criamos de um simples processo adotando o modelo em cascata, percebemos que o trabalho foi desenvolvido com muito mais qualidade e eficiência. Sendo assim, podemos concluir que a adoção de um modelo de processo produz resultados melhores à abordagem casual.

   Também foram apresentados os processos de desenvolvimento de software clássicos, tais como Modelo em Cascata, Prototipagem, Modelo Espiral, Incremental e Iterativo.

   Sugiro como leitura adicional o artigo O processo de software.

   Sugiro também os seguintes vídeos para aprimorar o conhecimento:

     Também aprendemos nesta aula um pouco sobre o processo RUP (Rational Unified Process).

     Para mais informações, acessem os links a seguir:

• RUP
• OpenUP: versão “light” e “ágil” do RUP

   Por hoje é só pessoal. Bons estudos!!!!

[ATPS 1] - Engenharia de Software

-Definições-

“Uma disciplina da Engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção desse sistema, depois que ele entrou em operação.”[ Sommerville ]

“Abrange o estabelecimento e o uso de sólidos princípios de engenharia, para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”[ Pressman ]

“Baseia-se no estudo e aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software.”[ IEEE Instituto de Engenheiros Eletricistas e Eletrônicos ]

“É a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em maquinas reais”[ Fritz Bauer ]

“È complexa, porem distinta e envolve múltiplas variáveis, tais como a arte, atendimento das necessidades humanas, conhecimentos científicos, conhecimentos empíricos, habilidades específicas, recursos naturais, formas adequadas, dispositivos, estruturas e processos. Não deve ser confundida com ciência da computação como um todo, pois ela usa resultados da ciência e fornece problemas para seus estudos.”[ Paula filho ]

De acordo com as definições apresentadas , não vejo muita divergência entre o objetivo de cada uma das definições , a não ser pelos modelos de processo que sim vão muito das necessidades explicitadas no projeto a finalidade final para todos ,no entanto ,em comum é uma técnica de sucesso para projetos de software e devem se apoiar num compromisso de qualidade.

-Atividades na Engenharia de Software-

O Processo de Software pode ser visto como um gerador de produtos, sendo que o produto final, ou principal, é o Software em si. É importante perceber que existem subprodutos que são gerados para cada fase -- ao final da fase de Especificação, por exemplo, é comum ter sido desenvolvido e entregue um ou mais documentos que detalham os requisitos do sistema.

Todo modelo de software deve levar em consideração as fases descritas; no entanto, cada um organiza estas fases de uma forma particular de acordo com sua filosofia de organização. Na próxima seção são analisados alguns modelos mencionados na literatura.

Um processo de desenvolvimento de software pode ser visto como um conjunto de atividades organizadas, usadas para definir, desenvolver, testar e manter um software. A seguir, alguns objetivos do processo de desenvolvimento:

• · Definição das atividades a serem executadas;
• · Quando determinada atividade deve ser executada;
• · Pessoa ou grupo a executar tais atividades;
• · Padronização no processo de desenvolvimento.

Existem diversos processos de desenvolvimento de software, no entanto há algumas atividades básicas comuns à grande parte dos processos existentes, nesse artigo será descrito algumas dessas atividades, como: Especificação; Projeto; Implementação; Testes; Implantação

Especificação

Esta atividade tem como objetivo, compreender o problema, dando aos desenvolvedores e usuários, a mesma visão do que deve ser construído para resolução do problema. Desenvolvedores e clientes, em conjunto, buscam levantar e priorizar as necessidades dos futuros usuários do software (necessidades essas denominadas como requisitos). O Levantamento de Requisitos é a etapa mais importante, no que diz respeito ao retorno de investimentos no projeto. Vários projetos são abandonados pelo baixo levantamento de requisitos, ou seja, membros da equipe não disponibilizaram tempo suficiente para essa fase do projeto, em compreender as necessidades dos clientes em relação ao sistema a ser desenvolvido. E como um sistema de informações geralmente é utilizado para automatizar processos de negócio em uma organização, esses processos da organização devem ser bem compreendidos para que o restante das atividades do processo de desenvolvimento flua de acordo com as reais necessidades do cliente.

Validação: tem por objetivo, assegurar que o sistema de software está atendendo às reais necessidades do cliente;

Verificação: verifica se os modelos construídos na análise estão em conformidade com os requisitos do cliente.

Projeto

Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.

No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a descrição realizada na fase de análise de requisitos.O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e projeto detalhado (ou projeto de baixo nível).Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura normalmente é realizado por um arquiteto de software. O projeto da arquitetura visa distribuir as classes de objetos relacionados do sistema em subsistemas e seus componentes, distribuindo também esses componentes pelos recursos de hardware disponíveis.Já no projeto detalhado, são modeladas as relações de cada módulo com o objetivo de realizar as funcionalidades do módulo. Além de desenvolver o projeto de interface com o usuário e o projeto de banco de dados.

Implementação

Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código-executável para o software.

Em um processo de desenvolvimento orientado a objetos, a implementação se dá, definindo as classes de objetos do sistema em questão, fazendo uso de linguagens de programação como, por exemplo: Delphi (Object Pascal), C++, Java, etc. Pode-se também utilizar na implementação ferramentas de software e bibliotecas de classes preexistentes para agilizar a atividade, como também o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias atividades, onde inclui-se geração de código-fonte, documentação, etc.

Testes

Diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto. Onde o principal resultado é o relatório de testes, que contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento em vários aspectos. Ao final dessa atividade, os diversos módulos do sistema são integrados, resultando no produto de software.

Implantação

Por fim a implantação compreende a instalação do software no ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de um software anterior, também é realizada a migração de dados anteriores desse software.

-Vantagens e Desvantagens-

Especificação :

• Vantagem- É de fundamental importância a compreensão total dos requisitos dos software para se obter sucesso
• Desvantagem- Má interpretação dos requisitos ,leva a maior parte dos erros encontrados durante os testes e a operação dos sistemas são derivados de um pouco entendimento

Projeto:

• Vantagem- descreve "como" o software será implementado . É durante a fase de projeto que a estrutura geral e o estilo são definidos
• Desvantagem- No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a descrição realizada na fase de análise de requisitos

Implementação:

• Vantagem- Esta fase é uma simples questão de tradução do projeto para um código, já que as decisões mais difíceis já foram tomadas durante a fase de projeto.
• Desvantagem- Caso não haja uma correta documentação do que esta sendo programado como um glossário , comentários etc ...

Teste :

• Vantagem- Assegurar que o software está realmente em acordo com suas especificações e livre de erros.
• Desvantagem-Não fazer tal validação de forma adequada pode comprometer a qualidade do projeto

Implantação :

• Vantagem- Interação do usuário com software , treinamentos de utilização e manutenção de alguns prováveis erros.
• Desvantagem- Se todas as partes do processo que antecedem essa não foram, de alguma forma bem sucedida , esse ultimo estagio pode ser bem mais demorado, consumido mais tempo e recursos financeiros.

-Relatório para Apreciação de Atividades-

Para apreciação de nosso Cliente ,cada fase do processo desenvolvido, existe uma série de atividades que são executadas. Estas atividades constituem um conjunto mínimo para se obter um produto de software.Observando as fases individuais e suas atividades associadas, combinando classificações é possível identificar as seguintes atividades:

1. Especificação :
1. Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extra-software.
2. Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento.
3. Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.
2. Projeto:
1. Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.
2. Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.
3. Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.
3. Implementação :
1. Codificação: a implementação em si do sistema em uma linguagem de computador.
4. Validação :
1. Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.
2. Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.
5. Implementação ,Manutenção e Evolução:
1. Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.
2. Compreende a instalação do software no ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso correto e adequado do sistema.

“A importância da computação na sociedade moderna tem aumentado o significado do conceito de qualidade de software. Dessa forma, o desenvolvimento de softwares é hoje uma tarefa fundamental e, em muitos casos, de missão crítica”

Bibliografias Utilizadas

1. Pressman, R.S. Engenharia de Software. São Paulo : Makron Books, 1995.
2. Degoulet, P., Fieschi, M. Introduction to Clinical Informatics. New York : Springer-Verlag, 1997.
3. Boehm, B.W. Software Engineering Economics. Englewood Cliffs : Prentice-Hall, 1981.
4. Murphy, G.F., Hanken, M.A., Waters, K.A. Electronic Health Records : Changing the Vision. Philadelphia : W.B. Saunders Company, 1999.
5. Ramamoorthy, C.V., Prakash, A., Tsai, W.T., Usuda, Y. Software Engineering : problems and perspectives. Computer. Outubro 1984. P.191-209.
6. Adelhard, K., Eckel, R., Holzel, D., Tretter, W. A prototype of a computerized patient record. Comput Methods Programs Biomed 1995 sep-oct; 48:115-9.
7. Davis, M.W. Computerizing Healthcare Information : Developing Electronic Patient Information Systems. Revised edition. New York: Mcgraw-Hill, 1998.
8. Von Mayrhauser, A. Software Engineering: Methods and Management. San Diego : Academic Press, 1990.
9. Dolin, R.H. Outcome analysis: considerations for an electronic health record. MD Comput 1997 jan-feb;14(1):50-6.

Thiago Cambiaghi dos Santos - 0850334

Marcelo Machado Gomes – 1801271201

José Dorival Jorge júnior – 1801281219

[ATPS 1] Engenharia de Software - Introdução e Principais Conceitos

“Engenharia de software é uma área do conhecimento voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de ciência da computação, gerência de projetos e outras disciplinas, objetivando produtividade e qualidade.
(Origem: Imasters).

“Engenharia é a atividade em que os conhecimentos científicos e técnicos e a experiência prática são aplicados para exploração dos recursos naturais, para o projeto, construção e operação de objetos úteis.”
(Origem: Wikipédia, a enciclopédia livre)

“O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”
(Origem: Fritz Bauer – 1969)

“A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software. O estudo de abordagens e princípios a fim de obter economicamente softwares confiáveis e que executem de forma eficiente nas máquinas reais”
(Origem: IEEE,1993)

“Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto.”
(Origem: Krakowak,1985)

Observando as definições acima podemos constatar que:
“Engenharia de software é um compilado de técnicas usadas na criação de ferramentas e programas necessárias para a resolução de problemas do dia de usuários que necessitam de praticidade e dinamismo de todas as atividades executadas, em todos os setores de serviços prestados que utilizam de computador como instrumento de execução de tarefas”


Definição básica das atividades a serem executadas

1. Quando determinada atividade deve ser executada;
2. Pessoa ou grupo a executar tais atividades;
3. Padronização no processo de desenvolvimento.

Existem diversos processos de desenvolvimento de software, no entanto há algumas atividades básicas comuns à grande parte dos processos existentes, algumas dessas atividades, São: Levantamento de requisitos; Análise de Requisitos; Projeto; Implementação; Testes; Implantação.

Levantamento de Requisitos

Esta atividade tem como objetivo, compreender o problema, dando aos desenvolvedores e usuários, a mesma visão do que deve ser construído para resolução do problema. Desenvolvedores e clientes, em conjunto, buscam levantar e priorizar as necessidades dos futuros usuários do software (necessidades essas denominadas como requisitos).
O Levantamento de Requisitos é a etapa mais importante, no que diz respeito ao retorno de investimentos no projeto. Vários projetos são abandonados pelo baixo levantamento de requisitos, ou seja, membros da equipe não disponibilizaram tempo suficiente para essa fase do projeto, em compreender as necessidades dos clientes em relação ao sistema a ser desenvolvido. E como um sistema de informações geralmente é utilizado para automatizar processos de negócio em uma organização, esses processos da organização devem ser bem compreendidos para que o restante das atividades do processo de desenvolvimento flua de acordo com as reais necessidades do cliente.

Análise de Requisitos

Esta etapa, também chamada de especificação de requisitos, é onde os desenvolvedores fazem um estudo detalhado dos dados levantados na atividade anterior. De onde são construídos modelos a fim de representar o sistema de software a ser desenvolvido.
O interesse nessa atividade é criar uma estratégia de solução, sem se preocupar como essa estratégia será realizada, ou seja, utilizar as necessidades dos clientes, depois de compreendido o problema, para resolução do problema solicitado. Assim é necessário definir o que o sistema deve fazer, antes de definir como o sistema irá fazer.
O que acontece com freqüência, é quando as equipes de desenvolvimento partem para a solução do problema do software, sem antes ter definido completamente o problema em questão. Nesta fase deve-se então realizar a validação e verificação dos modelos construídos, antes de partir para solução do problema.
Validação: tem por objetivo, assegurar que o sistema de software está atendendo às reais necessidades do cliente;
Verificação: verifica se os modelos construídos na análise estão em conformidade com os requisitos do cliente.

Projeto

Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.
No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a descrição realizada na fase de análise de requisitos.
O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e projeto detalhado (ou projeto de baixo nível).
Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura normalmente é realizado por um arquiteto de software. O projeto da arquitetura visa distribuir s classes de objetos relacionados do sistema em subsistemas e seus componentes, distribuindo também esses componentes pelos recursos de hardware disponíveis.
Já no projeto detalhado, são modeladas as relações de cada módulo com o objetivo de realizar as funcionalidades do módulo. Além de desenvolver o projeto de interface com o usuário e o projeto de banco de dados.

Implementação

Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código-executável para o software.
Em um processo de desenvolvimento orientado a objetos, a implementação se dá, definindo as classes de objetos do sistema em questão, fazendo uso de linguagens de programação como, por exemplo: Delphi (Object Pascal), C++, Java, etc. Pode-se também utilizar na implementação ferramentas de software e bibliotecas de classes preexistentes para agilizar a atividade, como também o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias atividades, onde se inclui geração de código-fonte, documentação, etc.

Testes

Diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto. Onde o principal resultado é o relatório de testes, que contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento em vários aspectos. Ao final dessa atividade, os diversos módulos do sistema são integrados, resultando no produto de software.

Implantação

Por fim a implantação compreende a instalação do software no ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de um software anterior, também é realizada a migração de dados anteriores desse software.




Bibliografia
www.imaster.com.br

ALUNOS: Bruno Cesar Bosso R.A 1801284739
Cristiano S. Nascimento R.A 1801261382
Vanessa Sena de Holanda RA 1804297868

[Aula] Ciclo de Vida de Desenvolvimento de Software

   Na aula desta semana aprendemos os conceitos referentes ao Processo de Software e ao Ciclo de Vida de Desenvolvimento de Software.

   Segundo FUGGETTA [1], um Processo de Software pode ser definido como um conjunto coerente de atividades, políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessários para conceber, desenvolver, dispor e manter um produto de software, ou seja:

"Um processo define quem está fazendo o quê, quando e como para alcançar um certo objetivo." Ivar Jacobson, Grad Booch e James Rumbaugh

   Compreendemos ainda que precisamos definir um Modelo de Ciclo de Vida ou Modelo de Processo que  pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto.

   Comentamos também nesta aula sobre qualidade de software, onde elicitamos os modelos de qualidade CMMI e MPS.BR. Ainda sobre o tema, tivemos a apresentação de um seminário muito interessante sobre MPS.BR. Parabéns aos alunos Bruno Henrique e Flávio Meira. A apresentação foi muito proveitosa. Um breve resumo foi postado neste blog.


   Alguns alunos gostariam de conhecer as empresas que passaram pelas avaliações CMMI e MPS.BR no Brasil. Sendo assim, segue o link de um blog que elencou estas informações:

• MPS.BR
• CMMI

    Por hoje é isso. Um excelente final de semana a todos!!!!!!

Referências:

• [1] Fuggetta, A. Software process: a roadmap, in Finkelstein, A. (ed.) The Future of Software Engineering, ACM Press, 2002
• [2] Wikipédia Engenharia de Software. Disponível em http://pt.wikipedia.org/wiki/Engenharia_de_software. Acesso em 19/08/2010.

[ATPS 1] Engenharia de Software

Definições:
Sommerville (1992) a engenharia de software é uma disciplina de engenharia relacionada a todos os aspectos de produção de software, envolve questões técnicas e não técnicas, tais como a especificação do conhecimento, técnicas de projeto e implementação, conhecimentos dos fatores humanos pelo engenheiro de software e ainda, gestão de projetos.
Maffeo (1992) a engenharia de software é: “a área interdisciplinar que engloba vertentes tecnológica e gerencial visando abordar de modo sistemático, processos de construção, implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos”.
Paula filho (2001) a engenharia de software é complexa, porem distinta e envolve múltiplas variáveis, tais como a arte, atendimento das necessidades humanas, conhecimentos científicos, conhecimentos empíricos, habilidades específicas, recursos naturais, formas adequadas, dispositivos, estruturas e processos. Não deve ser confundida com ciência da computação como um todo, pois ela usa resultados da ciência e fornece problemas para seus estudos.
Carvalho e Chiossi (2001) a engenharia de software é uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizados, desde a percepção do problema ate o momento que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software.
Roger S. Pressman engenharia de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em maquinas reais.
Podemos perceber claramente uma concordância de todos os estudiosos acima quanto à questão do uso de técnicas de engenharia na construção de software, muitos deles fazem referencia ao uso de técnicas já existentes, no entanto um vai mais além e fala da criação de princípios, o que pode ser considerado uma técnica valiosa, partindo do pressuposto que cada problema tem uma solução diferente e cada solução poderá ter um tratamento diferente para sua implementação. Podemos verificar também a concordância de alguns deles quanto à presença de fatores não humanos, justificando que a preocupação com fatores não técnicos também deve ser uma regra na construção de um software, porém há quem omita em sua definição a importância dos fatores humanos para o sucesso na construção de um software.

Atividades de desenvolvimento de software
Levantamento de requisitos:
A análise de requisitos é simplesmente o levantamento de todos os requisitos determinantes para o bom funcionamento de um software. Requisitos dividem-se em funcionais e não-funcionais.
Funcionais: determinam como o software irá funcionar, como deve se comportar a entrada de dados e qual serão as informações fornecidas como saída do processo:
Tipos de dados de entrada, Tipos de dados de saída, tipos de relatórios a serem emitidos, no geral são especificações que ajudam o analista na definição do que o sistema irá fazer.
Não funcionais não são necessários para o funcionamento do software:
A cor da tela, o tipo da letra usada nas telas, tamanho das telas, se serão de tamanho fixo ou não etc..
Analise dos requisitos
Nesta parte e feito um minuciosa analise dos dados colhidos na fase anterior para a validação dos requisitos, assim definido saberíamos o que o sistema devera fazer. É quando são definidas as classes necessárias para o desenvolvimento do software e determinantes para que este atenda as necessidades do cliente, também e feita a parte de diagramação do software definindo o relacionamento das classes, seqüência em que os dados serão processados, estados do objeto, diagramas de colaboração e outros, caso sejam necessários. A partir desses diagramas ficaria mais visível o modo que os sistema solucionaria o problema do cliente. No caso do nosso cliente definiremos quais classes o atenderia melhor e quais dados seriam necessários armazenar.
Projeto
Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.
No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a descrição realizada na fase de análise de requisitos.
O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e projeto detalhado (ou projeto de baixo nível).
Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura normalmente é realizado por um arquiteto de software. O projeto da arquitetura visa distribuir as classes de objetos relacionados do sistema em subsistemas e seus componentes, distribuindo também esses componentes pelos recursos de hardware disponíveis.
Já no projeto detalhado, são modeladas as relações de cada módulo com o objetivo de realizar as funcionalidades do módulo. Além de desenvolver o projeto de interface com o usuário e o projeto de banco de dados.

Implementação:
Nessa parte ocorre a implementação de tudo o que pesquisado e desenvolvido nos passos anteriores agora o sistema será efetivamente desenvolvido através da codificação na linguagem escolhida, ou em outras palavras escrever o código do software.
Testes
É hora de testar o funcionamento do programa, verificar qual o comportamento do sistema quanto à entrada de dados, saídas, tratamentos de erros, tempo de processamento e busca no banco, segurança e integridade. Não devemos esquecer que os testes não deverão ser feitos pelos programadores, pois se criam vícios de programação, o que poderia comprometer a qualidade do teste e conseqüentemente do software.
Implantação
Implantação do sistema consiste em colocar o software para funcionar no ambiente do cliente, instalação do sistema e do banco de dados e também contem a parte de treinamento de usuários, migração de dados caso seja necessário e suporte técnico.


Vantagens
Organização do processo de desenvolvimento:
Como vimos anteriormente o processo de produção de software seguindo a engenharia de sistemas define que passos bem definidos sejam cumpridos sem que outros sejam iniciados principalmente pela dependência entre eles.
Qualidade final:
Devido à grande organização técnica e especificação definida de processos de desenvolvimento, a qualidade do produto e indiscutível.
Facilidade de manutenção:
Devido a quantidade de documentação exigente e a distribuição de componentes e classes o sistema se torna mais fácil de manter.
Custo benefício:
Geralmente o custo benefício de um software desenvolvido usando técnicas de engenharia de são mais gratificantes, possuem vida mais longa e mais possibilidade de evolução

Desvantagens
Clientes desinformados:
Os clientes não estão familiarizados com as linguagens de especificação formal, o que pode conduzi-lo ao não financiamento de projetos com este tipo de especificação.
Engenheiros inexperientes:
Dificuldade de engenheiros de software em formalizar e desenvolver especificações devido à falta de experiência.


Custo elevado:
Dificuldade em demonstrar por que o cliente deve pagar por um custo mais alto devido a sua falta de informações técnicas.
Falta de ferramentas dirigidas voltadas para a implementação:
Poucas ferramentas dirigidas para a implementação, já que o grande foco da disciplina tem um nível altamente teórico voltado a documentação e especificação de processos.

RELATORIO DE IFORMAÇOES INICIAIS
À RSLB Consultoria S/A
Introdução
Este relatório serve para a apreciação das vantagens que a engenharia de software pode oferecer para desenvolvedores na construção de sistemas computacionais e também as principais atividades a serem desenvolvidas na construção do software.
1. A engenharia de software
Reunindo as definições de autores consagrados, poderíamos dizer que, a engenharia de software e a disciplina obrigatória na construção, gerenciamento e manutenção de sistemas computacionais visando à qualidade, economia e satisfação do cliente quanto ao produto final, pois devido as suas técnicas e métodos bem definidos quanto ao processo de produção de softwares.
2 A construção do sistema
Como atividade inicial, faremos uma visita vossa empresa no intuito de conhecer o ambiente de produção, venda e logística da empresa como beneficio desta visita poderíamos fazer um breve levantamento de processos existentes bem como estrutura de rede caso exista e o nível de familiarização dos funcionários com sistemas computacionais, tanto nível operacional, estratégico operacional, e estratégico gerencial. Logo após partiremos então para a realização de atividades voltadas a construção do novo sistema, algumas dela tem participação direta do cliente, as quais citarei abaixo:
2.1 Levantamento de requisitos:
A parte da análise de sistemas que busca reunir todas as informações necessárias para que produto final de software possa atingir as amplas expectativas do cliente. Não podemos deixar de incluir o hardware na lista de requisitos.
22.2 Análise de requisitos:
Os requisitos apresentados pelo cliente podem não serem necessários ou viáveis para a construção do sistema, cabe aos profissionais envolvidos no projeto a perfeita análise dos requisitos e validar aqueles realmente necessários para a perfeita conclusão do trabalho.
Demais processos não requerem a participação direta do cliente, portanto não serão descritos, principalmente pelo seu baseamento técnico e cientifico o que poderia ir alem do conhecimento do cliente.
III Apresentação da produção
Podemos definir junto ao cliente uma política de apresentação periódica do andamento da produção, como projeto de interfaces e módulos a medida em estes forem produzidos estabelecendo assim uma política de integridade e confiança já que a aprovação final do serviço será dada por ele.
VI. Conclusão
Podemos concluir neste estudo inicial, será imprescindível o uso de técnicas de engenharia de software na construção do sistema, visto que fazendo uma comparação das vantagens e desvantagens em se usar estas técnicas as desvantagens tornam-se praticamente ignoráveis, alem da cientificidade quanto a técnicas de organização de etapas de construção.
Poderíamos dizer que usar a engenharia de software como base para a produção do sistema e a garantia que o produto final será o melhor possível.
Gostaria de ressaltar também a grande importância do cliente nessa primeira etapa de levantamento e analise de requisitos, vendo que as informações passadas por ele provavelmente definirá o formato do produto final e não deixando de lembrar-los que todas as mudanças requeridas deverão ser comunicadas imediatamente a gerencia do projeto para que possam tomar as decisões de forma rápida e eficaz.
Bibliografia
Roger s Pressman (engenharia de software 6°edição, Mc Graw Hill, 2006);
Sommerville (engenharia de software 8° edição, Pearson Prentice Hall, 2007);
Denis Alcides Rezende (engenharia de software e sistemas de informação 3°edição, Brasport, 2005);
Shari Lawrence Pfleeger (engenharia de software teoria e pratica 2°edição, Pearson Prentice hall, 2004)
http://www.scribd.com/doc/33799321/Trabalho-Engenharia-de-Software-Davi


Claudio Márcio Gonçalves Ra:1816323420
Elizeti Nericke Ra: 0850254
Carlos Alessandro Soares Ra: 1801241420

[ATPS 1] ENGENHARIA DE SOFTWARE

AUTORES E DEFINIÇÕES

Jocélio Passos
Engenharia de Software é uma estratégia sistemática, disciplinada e quantificável para a Programação. Envolve o desenvolvimento, operação e manutenção do software

Leôncio Regal Dutra

É o estabelecimento e uso de sólidos princípios de engenharia visando obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais.

Jair Cavalcanti Leite

Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantido suas qualidades. Além disto, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento.

Fritz Bauer

Engenharia de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais.

Pressman, Roger S. (1995) afirma que engenharia de software abrange o estabelecimento e o uso de sólidos princípios de engenharia, para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Abrange um conjunto de três elementos fundamentais - métodos, ferramentas e procedimentos. Os métodos proporcionam os detalhes de “como fazer”. As ferramentas dão apoio automatizado aos métodos, tais como CASE, CAD, análise estruturada e orientação a objetos. Os procedimentos constituem o elo entre ambos e possibilitam o desenvolvimento racional e oportuno do software.


Conclusão:

A Engenharia de Software visa utilizar conceitos da Engenharia na obtenção um software que realmente funcione, que também seja confiável e barato.


Atividades a serem executadas

Levantamento de Requisitos

Nesta atividade é feita uma analise das funcionalidades do sistema, levantando os requisitos necessários para que o sistema atenda as necessidades do cliente.
Nesta etapa também descreve todas as funcionalidades que o sistema terá.

Análise de Requisitos
Descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação do sistema. É feito um estudo detalhados dos dados levanados.
O interesse nessa atividade é criar uma estratégia de solução, sem se preocupar como essa estratégia será realizada, ou seja, utilizar as necessidades dos clientes, depois de compreendido o problema, para resolução do problema solicitado. Assim é necessário definir o que o sistema deve fazer, antes de definir como o sistema irá fazer.

Projeto

Projeto Arquitetural: onde é desenvolvido um modelo conceitual
para o sistema, composto de módulos diagramas conceituais, blocos descritivos com funcionalidades do sistema.
Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definidas no projeto arquitetural.
Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.

Implementação
Neste processo, é codificado os processos e requisitos em uma linguagem de programação, gerando o executável do software que será feito os testes e que irá para o cliente.
Testes

Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.

Implantação

A implantação compreende a instalação do software no ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de um software anterior, também é realizada a migração de dados anteriores desse software.

Vantagens e desvantagens em se criar um software baseado em Engenharia de Software
Desvantagens:

• O processo de prototipação pode dar ao usuário final a impressão que praticamente qualquer sugestão pode ser implementada, não importa qual estágio do processo de desenvolvimento se está.

• Além disso, para os usuários não está claro o porquê da demora

• Como o processo é iniciado antes da criação do programa, muitas vezes, podem ocorrer problemas não previstos anteriormente, após a concepção do programa.

• O gerenciamento de criação de softwares torna difícil aperfeiçoar o processo geral, assim como também dificulta o alinhamento entre o desenvolvimento da aplicação e as necessidades do negócio.

• O tempo de desenvolvimento do Software geralmente supera o esperado

Vantagens

• Os profissionais têm controle sobre o desenvolvimento de software dentro do que foi estabelecido.

• Através da utilização dos conceitos de Engenharia de Software podemos criar um software realmente confiável e visando a plena funcionalidade do mesmo.

• Na Engenharia de Software, são utilizados sólidos princípios para o obtenção de um produto o mais próximo possível da real necessidade do usuário.

• Uso de métodos e processos trará ao profissional um total controle da qualidade do produto final.

• Têm-se um total controle do andamento do projeto.


ANDERSON SILVA 1820000801
CARLOS CEZAR GOMES 0850282
DANILO SANTOS DA SILVA 0850239
RODRIGO ISRAEL 1803296079

[Seminário] O Processo Unificado Integrado ao Desenvolvimento Web

O Processo Unificado Integrado ao Desenvolvimento Web

ANTONIO CLEITON
JULIANO HENRIQUE BUZANA
5º SEMESTRE DE TADS – FACULDADES ANHANGUERA DE CAMPINAS
PROFª. TANIA REGINA RAMIRES BEZERRA
1º Introdução ao Processo Unificado;

O Processo Unificado (UP) é um processo de desenvolvimento fortemente ligado à orientação a objetos, porém, podendo ser adaptado para outros tipos de projetos.
Algumas características básicas do Processo Unificado são:
Direcionado por Casos de Uso: Com o intuito de se definir uma linguagem entre os usuários e o sistema;
Centrado na Arquitetura: Modelando uma arquitetura através dos aspectos estáticos e dinâmicos do projeto utilizando-se dos Casos de Uso mais significativos;
É iterativo e Incremental: Dividindo-se todo o projeto em mini-projetos menores.
O Processo Unificado consiste em atribuir tarefas a grupos ou indivíduos envolvidos diretamente no desenvolvimento de um Projeto, definindo o quanto antes, quais as etapas (iterações) e os artefatos que serão envolvidos durante o processo.

1 Visão Geral do Processo Unificado

2º Fases do Processo Unificado;

Concepção ou Iniciação:
Viabilizar o projeto, riscos, projetar os casos de uso mais críticos definindo quantas iterações o projeto terá.
Elaboração:
Definição dos casos de uso e seu detalhamento. Apresenta-se a Baseline completa do projeto, bem como os componentes que farão parte da equipe de desenvolvimento.
Construção:
Unem-se os vários artefatos de software tendo uma visão geral de como o Baseline do projeto está sendo seguido.
Transição:
Garantir que todos os requisitos do projeto foram atendidos e implementados corretamente podendo tirar uma visão geral do projeto.

Fluxos de Trabalho:
Modelo do Negócio:
Garantir que o fornecedor entenda exatamente o problema a ser resolvido. A iteração cliente e fornecedor torna-se essencial. Entender o modelo de negócio do cliente é peça fundamental antes que um requisito possa ser definido.
Requisitos:
A principal tarefa é a extração dos principais requisitos do sistema. Para isso, o fornecedor precisa ter em mente o problema a ser resolvido de forma que possa extrair ao máximos os requisitos.
Análise e Projeto:
Desenvolve-se uma visão arquitetural do sistema compreendendo os casos de uso mais importantes que serão usados na elaboração de alguns artefatos, tais como: um diagrama de classes, de iteração, de seqüência, etc.
Implementação:
Nesta Fase, os desenvolvedores poderão utilizar-se de componentes utilizados em outros sistemas (Componentização ou Modularização).
Testes:
Define-se um Plano de Testes deve ser elaborado e colocado em prática, podendo ser utilizado durante todo o projeto.
Implantação:
É a instalação do sistema no ambiente do cliente. Pode-se recriar o ambiente de trabalho do cliente para que já na fase de Teste, possa se ter uma idéia mais próxima possível do desempenho do sistema.
Gerência de Configuração e Mudança:
Controla-se todos os artefatos do sistema, bem como suas versões. Um bom controle de mudança é crucial para garantir o sucesso e a qualidade do projeto.

Gerenciamentos do Projeto:
Escolhe-se os artefatos a serem utilizados no desenvolvimento da aplicação.
Ambiente:
Representa o fluxo de trabalho da empresa que desenvolverá o projeto.


3º Artefatos Específicos Utilizados no Desenvolvimento de Projetos Web;

Planilha de Requisitos
Uma planilha em Excel, ou programa similar, para organizar os principais requisitos do sistema.

Planilha de Requisitos

Projeto Linear
Mapea-se os requisitos do sistema com as áreas ou páginas de uma aplicação. Cada página receberá um código, que por sua vez, será relacionado com nenhum, um ou mais requisitos.

Projeto Linear e Requisitos

Web Content

É um artefato de software responsável pelo armazenamento de todo o conteúdo textual utilizado em um site.
Ele é formado de acordo com os requisitos de sistema de acordo com as várias seções.

Ilustração de uma Página do Web Content

FDD (Wireframes)

O FDD (Functional Design Document) é um conjunto de Wireframes onde cada um representa uma página da aplicação. É uma maquete da página Web usada somente para apresenta a disposição dos elementos, não à estética.

Wireframe (Página do FDD)

Protótipo de Interface

Pode ser uma parte da aplicação, protótipo de funcionalidade ou de uma proposta de layout feita pelo designer e aprovada pelo cliente. Sua principal função é fornecer ao cliente quais serão as cores básicas da aplicação, uma parte da arquitetura de informação e como ficarão disponibilizadas aos usuários dentro do site.

4º Configurando o Processo Unificado;

Define-se o tempo de cada iteração dentro das fases.

Fases Tempo Iterações
Concepção 1 semana 1
Elaboração 2,5 semanas 1
Construção 6 semanas 2
Transição 2,5 semanas 1
Divisão das fases do projeto

Artefatos Concepção Elaboração Construção Transição
Planilha de requisitos 30% 50% 15% 5%
Projeto Linear 20% 70% 10% 0%
Web Content 15% 70% 15% 0%
FDD (Wireframes) 10% 60% 30% 0%
Protótipo de Interface 100% 0% 0% 0%
Mensuração de Esforço X Fases

Fase Concepção - 1ª. Iteração

A 1ª iteração ocorre praticamente depois de toda a fase de concepção do projeto, deixando-se claro quais os artefatos farão parte da gerência de configuração e mudança.
Modelo de negócio: Neste fluxo, se o fornecedor achar necessário, pode-se realizar um documento indicando a análise de viabilidade e de risco do projeto.
Requisitos: A extração dos requisitos deve ser feita à medida que os casos de uso do sistema são realizados e validados.
Análise e Projeto: Este fluxo utilizará até o momento, todos os requisitos construídos e aprovados dentro da planilha. A arquitetura de informação descrita no Projeto Linear já pode ser montada se baseando nos requisitos.
Mediante a construção do Projeto Linear e do Web Content, inicia-se a montagem FDD. O FDD servirá como guia para o designer montar o protótipo de interface do site. A finalização do protótipo e a aprovação do cliente marcam o final da 1ª iteração.
Implementação: Nesse momento os desenvolvedores podem, por exemplo, buscar funções e componentes já desenvolvidos em outros projetos, os quais servirão para a realização desta aplicação.
Teste: Esse fluxo pode ser marcado com o início da construção de um artefato chamado plano de teste. Essa construção deverá ser direcionada pelos requisitos do sistema obtidos até o momento.
Implantação: Não há.

Ao final dessa iteração, têm-se os seguintes artefatos sob gerência de configuração e mudança: FDD, Projeto Linear, Web Content, Planilha de requisitos, descrição dos casos de uso, plano de teste, documento de Baseline e quaisquer outros artefatos da UML que podem ser incluídos mediante a necessidade do projeto.

Fase Elaboração - 2ª. Iteração

No contexto apresentado, a 2ª iteração abrange toda a fase de elaboração do projeto.
Modelo de negócio: Análises de viabilidade e de riscos podem e muitas vezes devem continuar sendo feitas. O domínio do problema deve ser entendido completamente e uma solução deve ser descrita através dos casos de uso que estarão 80% finalizados no final desse fluxo de trabalho.
Requisitos: Os requisitos continuam sendo extraídos dos casos de uso e compondo a planilha. No final dessa iteração tem-se 80% dos requisitos já documentados e aprovados pelo cliente.
Análise e Projeto: Os requisitos aprovados até o momento servirão como base para a quase completa formação do Projeto Linear, do Web Content e consequentemente do FDD.
Implementação: Inicia-se a junção de todas as funções e componentes pesquisados no início do projeto, com os artefatos desenvolvidos até o momento. Os desenvolvedores precisam estar aptos a entender não só os artefatos como o FDD, Web Content e o Projeto Linear, mas também os possíveis diagramas da UML e, principalmente os requisitos gerados até o instante.
Teste: Esse fluxo pode apresentar alterações no plano de teste devido ao número de requisitos já extraídos. Em conjunto com a fase de implementação, são realizados testes de módulos, com objetivo de verificar o que está sendo feito.
Implantação: De forma a verificar se o que está sendo feito em relação à codificação irá funcionar do lado do cliente, no final dessa iteração, tem-se a implantação do que já foi codificado até o momento.

No final desta iteração, os artefatos estarão quase que totalmente concluídos. Eventuais ajustes podem ocorrer na Baseline e devem ser feitos pelo gerente do projeto. A RTF é construída avaliando e formalizando toda a iteração, servindo de aprendizado e preparando os envolvidos para a próxima fase do projeto.

Fase Construção - 3ª e 4ª Iteração

Neste contexto, a 3ª e 4ª iterações irão compor toda a fase de construção do projeto. Mais especificamente, a 3ª iteração indica o meio da fase de construção, enquanto que a 4ª, marca o final dessa fase. Eventuais ajustes nos artefatos surgirão em razão da implementação.
Modelo de negócio: As análises de viabilidade e de risco diminuem e servem agora apenas para pequenas tarefas realizadas no decorrer do projeto.
Requisitos: Os requisitos ainda continuam sendo extraídos dos casos de uso e compondo a planilha. No final dessa iteração, tem-se em torno de 95% dos requisitos já documentados e aprovados pelo cliente. Dessa forma, o FDD, o Web Content e o Projeto Linear, estarão também, quase completamente elaborados.
Análise e Projeto: Alguns artefatos da UML, escolhidos para melhor representar as características do sistema, serão finalizados durante essas iterações.
Implementação: Os programadores deverão possuir um suporte quase completo dos artefatos Web citados anteriormente. A maioria dos esforços do projeto são voltados agora para implementação e para a gerência das possíveis mudanças nos requisitos e conseqüentemente nos artefatos.
Teste: Nesse fluxo, consegue-se entender os pontos críticos de implementação e elaborar o plano de teste quase que totalmente.
Implantação: À medida que a codificação é finalizada, uma versão executável do sistema poderá ser implantada no ambiente do cliente.

Fase Transição - 5ª Iteração

Esta é a última iteração do exemplo apresentado neste artigo, integrando o desenvolvimento Web com o Processo Unificado. O final dessa iteração marca o término do projeto, bem como a construção completa de todos os artefatos.
Modelo de negócio: Dificilmente nesta etapa existirão tarefas que exijam análises de viabilidade e de risco.
Requisitos: Os requisitos nesse fluxo são mínimos. É mais comum encontrar alguns requisitos de engenharia (não funcionais) devido à parte do sistema já implantada no cliente.
Análise e Projeto: Nesse fluxo, tem-se a finalização do FDD, Web Content e do Projeto Linear. Os artefatos da UML também serão finalizados durante essa iteração.
Implementação: O ideal é que os desenvolvedores façam ajustes no sistema, apenas para a adaptação ao ambiente do cliente. Pouquíssimas alterações nos requisitos funcionais devem ser realizadas nesse fluxo e conseqüentemente, poucas modificações no sistema.
Teste: Nesse fluxo, o documento de plano de teste será finalizado. Testes de sistemas e de validação podem ser realizados também pelo cliente.
Implantação: A versão executável final do sistema deverá ser colocada no ambiente de teste e posteriormente no ambiente de produção do cliente, mediante aprovação do mesmo.

Conclusão

Neste artigo, procurou-se mostrar como artefatos específicos, utilizados no desenvolvimento de projetos Web, podem ser usados durante a construção de um sistema baseado no Processo Unificado.

[ATPS 1] Definições – Engenharia de Software

Passo I
Definições – Engenharia de Software
"Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais".
Friedrich Ludwig Bauer

“A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software. O estudo de abordagens e princípios a fim de obter economicamente softwares confiáveis e que executem de forma eficiente nas máquinas reais”
IEEE, 1993

“Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto”
Krakowak,1985

“É uma das áreas da Engenharia que trata dos aspectos de produção de software.
O seu objetivo é estabelecer uma sistemática abordagem de desenvolvimento, através de
ferramentas e técnicas apropriadas, dependendo do problema a ser abordado,considerando restrições e recursos disponíveis.”
Prof. Thiago Eugênio.

“O desenvolvimento e a aplicação de ciência, matemática, técnicas, métodos e ferramentas para o desenvolvimento e a manutenção econômica de software de qualidade preditível e controlável, operando de modo econômico em máquinas e ambientes reais”
Arndt Von Staa, 1987.

Com base nas definições de autores diferentes, percebemos que ambos possuem o mesmo padrão sobre engenharia de software, na qual se resumem na obtenção no melhor desenvolvimento de um software, sendo eles: econômico, confiável e que utilizem técnicas eficientes para sua manutentabilidade e qualidade.

Passo II

As atividades básicas envolvidas no desenvolvimento de software, são as seguintes:
• Concepção;
• Elaboração;
• Construção;
• Transição;
Dentro das etapas citadas acima temos o fluxo de trabalho abaixo:
• Modelagem de negócios;
• Requisitos;
• Análise de Design;
• Implementação;
• Teste;
• Implantação;
• Gerência de Configuração e Mudança;
• Gerenciamento de Projetos;
• Ambiente.

Passo III

As vantagens em se desenvolver um software baseando-se nos conceitos de engenharia de software são: qualidade no decorrer do processo, estabelecer o custo benefício, viabilidade, eficiência em maquinas reais e sua confiabilidade. Pois seguindo todos os passos para a conclusão de seu desenvolvimento obteremos maior acuracidade em suas etapas, evitando que fique pontos descobertos ou a serem trabalhados, garantindo assim disponibilidade de serviços essenciais.

Antonio Cleiton, Joyce Scarazzati, Juliano Buzana e Lilian da Palma

[ATPS 1]

Bruno Henrique dos Santos RA..:1801273107
Flavio Meira RA..:0850223
POF: Tânia Ramires

Autores : SOMMERVILLE/Fritz Bauer/IEEE/PRESSMAN/Krakowak

A engenharia de software é uma tecnologia baseada em camadas e, que fornece vários modelos abstratos e precisos e técnicas que permitem o engenheiro analisar os requisitos de sistema, projetar, programar e manter sistemas, dando assim o apoio para a construção e desenvolvimento de software com qualidade.A Engenharia de software segundo Fritz Bauer “é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em maquinas reais”. Já IEEE desenvolveu uma definição mais abrangente que é “(1) aplicação de uma abordagem sistemática, disciplinada e quantificável, para desenvolvimento, operação e manutenção do software, isto é a aplicação da engenharia ao software. (2) Os estudos de abordagens como as de (1)”. (PRESSMAN, 2006).Por outro lado, de maneira mais simples, Krakowak define engenharia de software como um Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto
Atividades básicas envolvidas no desenvolvimento de software

Definição do escopo do projeto, calculo do recurso humano de acordo com o projeto solicitado, monitoramento do projeto em relação ao estabelecido no plano do projeto, definir os requisitos juntos os fornecedores de requisitos (Pessoa escolhida para informar as necessidades do projeto) e a medição de andamento do projeto.

Desvantagens de se desenvolver um software baseando-se em
definições e conceitos sobre Engenharia de Software

Por ter muitas definições no conceito de engenharia abrangeu uma enorme globalização, assim fazendo aparecer muitos diversidades de conceitos.
Engenharia de software quando não é bem coordenada leva ao descontentamento dos envolvidos no projeto pois não é permitido que alterações no escopo sejam feitas

Vantagens de se desenvolver um software baseando-se em
definições e conceitos sobre Engenharia de Software

Evitar que o projeto fuja do que foi solicitado pelo cliente Acompanhamento do desenvolvimento (passo a passo) Facilidade para resolver alterações do escopo
Participação constante dos interessados (clientes)Determinar com maior precisão o tempo do projeto