UM POUCO DE ENGENHARIA DE SOFTWARE

Esse post é baseado no resumo que fiz do artigo Alguns Fundamentos de Engenharia de Software do Wilson de Pádua Paula Filho publicado na revista Engenharia de Software Magazine.

Pra começar ele define a diferença entre ciência e engenharia como:

Ciência - Conjunto organizado de conhecimentos
relativos a um determinado objeto, especialmente
os obtidos mediante a observação, a
experiência dos fatos e um método próprio.
Engenharia - Arte de aplicar conhecimentos
científicos e empíricos e certas habilitações
específicas à criação de estruturas, dispositivos
e processos que se utilizam para converter
recursos naturais em formas adequadas ao
atendimento das necessidades humanas.

Com base na definição descrita podemos dizer que a ciência foca no acumulo de conhecimento através de métodos científicos ( baseado em experimentos e observações ) e a engenharia aplica os conhecimentos da ciência e "da" uma utilização a eles que irá melhorar alguma necessidade humana.

Na Engenharia de Software podemos definir o software como um produto . Estando fora de seu escopo programas feitos com o objetivo de agradar ao programador, programas descartáveis ( feitos para resolver o problema da pessoa que o fez sem a utilização por outras pessoas ).
Para entrar no escopo é necessário ser um produto que tenha um investidor que esteja disposto a pagar por ele ( intenções de lucro), pessoas que irão utilizá-lo (pode ser que o produto seja feito por encomenda com o intuito de atender a necessidade de um cliente específico ou feito "em massa" ou produto de prateleira - como define o autor, que tem como objetivo atender a um número maior de usuários).

O autor define o ciclo de vida sendo:

• concebido para tentar atender a uma necessidade ( faz sentido neh?)
• especificado, quando essas necessidades são traduzidas em requisitos viáveis
• desenvolvido, transformando-se em um conjunto formado por código e outros itens, como modelos, documentos e dados
• passa por algum procedimento de aceitação e é entregue ao cliente ( em alguns casos passa para clientes estratégicos fazerem os testes juntamente com a equipe de desenvolvimento para analisarem requisitos como consistencia de dados, usabilidade, bla bla bla...)
  
• entra em operação, é usado, e sofre atividades de manutenção, quando necessário ( sempre há o que melhorar no software e sempre ha algum bug =[ )
  
• retirado de operação ao final de sua vida útil.(afinal de contas, nada é pra sempre neh? mesmo porque com o avanço da tecnologia sempre encontra-se uma forma melhor de resolver o mesmo problema... tirando o caso do cobol nos bancos que ainda nao encontraram.. hehehe..)

Outra coisa importante são as DATAS e EQUIPE!
Todo projeto tem data de início, data de fim, uma equipe e outros recursos. O responsável pelo projeto é chamado de gerente de projeto ( ou líder de projeto) e o que ele faz já foi definido no outro post sobre... Gerencia de projeto.. se não me engano...
Ele também define" O trabalho realizado dentro de um projeto pode ser descrito por um conjunto de atividades, que podem possuir relações de dependência, paralelismo, e decomposição em atividades mais elementares" e que "próprio produto é um resultado concreto associado ao marco de conclusão do projeto, que pode ser utilizado sozinho, ou como componente de um sistema."

Agora iremos falar sobre PMI ( Project Managment Institute), que é uma organização internacional que tem o objetivo de difundir e promover boas práticas de gestão de projetos. Com essa finalidade ela administra programas de certificação de profissionais nessa área e publica o guia PMBOK ( Project Managment Body of Knowledge).

Nessa guia "define-se um projeto como um empreendimento temporário realizado para criar um produto, serviço ou resultado distinto. Um produto, por sua vez, é definido como um objeto produzido, quantificável e que pode ser um item final ou um item componente. Uma atividade é definida como um componente de trabalho realizado durante o andamento de um projeto. Os relacionamentos entre as atividades que compõem um projeto são mostrados em uma estrutura analítica, que o PMBOK define como uma decomposição hierárquica orientada à entrega do trabalhoa ser executado pela equipe do projeto, para atingir os objetivos do projeto e criar as entregas necessárias. Estruturas analíticas de projeto podem ser apresentadas de muitas maneiras. Diagramas de atividade são uma das representações mais usadas atualmente. Outro tipo de representação usual é fornecida por planilhas e cronogramas, como aqueles que são produzidos pela ferramenta Microsoft Project."

"O PMBOK é um exemplo de modelo de referência: uma estrutura de conhecimentoque organiza conceitos, práticas e padrões de uma área." Ou seja, ele diz O QUE FAZER, E NÃO COMO FAZER! Não confunda!!

Outro modelo de referência citado pelo autor é o CMMI ( Capability Maturity Model Integration), formulado pelo Software Engineering Institute da Carnegie-Mellon University . Uma curiosidade que o autor cita é que o CMMI foi uma encomenda do Pentágono, que o utiliza para avaliação da capacidade de seus fornecedores de software e ele tem grande aceitação na indústria americana.
Ta... o importante é saber que o CMMI têm raizes em comum com o PMBOK, como pode-se observar ( segundo o autor):
"Produto - Resultado que se pretende entregar a um cliente ou usuário.
Projeto - Conjunto gerido de recursos inter-relacionados, que entrega um ou mais produtos a um cliente ou usuário, com início definido e que, tipicamente, opera conforme um plano.
Estrutura analítica do projeto - Um arranjo dos elementos do trabalho e dos relacionamentos deles entre si e com o produto final."

SÓ QUE, diferente do PMBOK, o CMMI também foca as aplicações dos processos e desenvolvimento de produtos( área técnica), enquanto o PMBOK se limita nas áreas de gestão de projetos.

Segundo a PMBOK um processo é um conjunto de ações e atividades inter-relacionadas, realizadas para obter um conjunto especificado de produtos, resultados ou serviços.

Segundo o autor, " processos, pessoas e tecnologia constituem os fatores de produção, que determinam o grau de sucesso dos projetos".

Ta acabando, caro leitor, calma!

Podemos definir a importância de modelos de referência como a CMMI para "mostrar o caminho das pedras e o mapa da mina: onde a experiência coletada indica que o investimento em melhorias é mais rentável, em cada passo da evolução das organizações"

Conclusão!

"A Engenharia de Software visa à criação de produtos de software que atendam as necessidades de pessoas e instituições e, portanto, tenham valor econômico. Para isso, usa conhecimentos científicos, técnicos e gerenciais, tanto teóricos quanto empíricos. Ela atinge seus objetivos de produzir software com alta qualidade e produtividade quanto é praticada por profissionais treinados e bem informados, utilizando tecnologias adequadas, dentro de processos que tirem proveito tanto da criatividade quando da racionalização do trabalho."

Ufa.. por hora é soh.. mais tarde trabalharemos mais sobre PMBOK e CMMI...