Uma breve introdução a Engenharia de Software

Prévia do material em texto

Uma breve introdução a Engenharia de Software
Segundo Sommerville, engenharia de software é uma disciplina de engenharia que trata de todos os aspectos relacionados à produção do software. O seu objetivo é produzir software de qualidade, com custo adequado e em tempo hábil. A Engenharia de Software envolve diversos estudos, metodologias e técnicas que visam aperfeiçoar a produção de software. Dentre elas pode-se destacar: O planejamento e gerenciamento do desenvolvimento de software, processos de desenvolvimento de software, metodologias ágeis, engenharia de requisitos, arquitetura de software e padrões de projeto, validação e verificação de sistemas e qualidade de software.
Um exemplo clássico de sistemas no qual foram desenvolvidos sem uso de metodologia, técnicas ou práticas bem definidas aconteceu nos anos 70. Nesta época projetos estouravam fora do orçamento, fora do prazo, tinha baixa qualidade, boa parte deles não atingia aos requisitos e eram de difícil manutenção.
Uma das características na engenharia de software é a necessidade de ter um planejamento e gerenciamento adequado para o projeto. Tendo em vista que a criação de um software pode ser encarada como um projeto, a engenharia de software utiliza como base os conceitos de gerência de projetos, como é o caso, por exemplo, os conceitos do Project Management Body of Knowledge (PMBOK). De acordo com o PMBOK, o gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender os requisitos das partes interessadas.
Ele define que o ciclo de vida de um projeto é dividido em cinco fases: iniciação, planejamento, execução, controle e finalização. Na fase de iniciação, o levantamento inicial dos riscos e requisitos do projeto é realizado, a viabilidade do projeto é analisada e se obtêm a autorização para início do projeto. Já na fase de planejamento, os objetivos são refinados, as atividades são definidas, o esforço e o custo do projeto são estimados, os riscos identificados são analisados e detalhados e o cronograma é elaborado dando origem ao plano de projeto. Na fase de execução, as ações planejadas são executadas, objetivando atingir os resultados esperados. Já a fase de controle é responsável por acompanhar o planejamento e execução do projeto, de modo a propor ações corretivas e preventivas, no menor espaço de tempo possível, após a detecção de anormalidade.
A fase de finalização do projeto consiste na entrega final do produto gerado e análise dos resultados obtidos. Nesta fase, a aceitação do produto pelo cliente é verificada e o desempenho do projeto em termos de custo, escopo e cronograma é consolidado. Embora apresentem necessidades comuns, o gerenciamento de projetos que envolvem o desenvolvimento de software distingue dos demais em dificuldades como, por exemplo, estimar o tempo de desenvolvimento, mensurar a evolução do projeto e medir a aceitação do produto, antes deste ser entregue ao cliente. Diante de tais diferenças, os gerentes de projetos de software costumam seguir processos de desenvolvimentos a fim de honrar os cronogramas e produzir produtos de qualidade.
O processo de desenvolvimento de software compreende todas as atividades, ações e tarefas envolvidas no desenvolvimento do software e a forma como estes elementos se relacionam definem um modelo. Atualmente existem inúmeros modelos de processos de desenvolvimento de software, dentre eles pode-se destacar: o cascata, o evolutivo, o incremental, o espiral, o RUP, o Extreme Programming (XP) e o Scrum.
O modelo cascata foi o precursor dos modelos de processo de desenvolvimento de software. Este modelo é constituído de cinco fases executada sequencialmente, ou seja, uma fase só é iniciada quando a anterior é completada. A dificuldade em atender mudanças no decorrer do processo e a demorar na disponibilidade de uma versão operacional do produto são os problemas encontrados neste modelo.
Diante das limitações do modelo cascata, foram criados os modelos evolutivo e incremental. A ideia do primeiro é entregar uma versão inicial do produto para avaliação do cliente e, em seguida, refinar o produto repetidamente até que uma versão atenda suas expectativas. O desenvolvimento exploratório e a prototipação são exemplos deste modelo. Já o modelo incremental, se diferencia do evolutivo uma vez que a entrega inicial é um produto que atende os requisitos básicos do cliente e sua construção é feita por meio de incrementos (modificação e adição novas funcionalidades).
O RUP é um modelo de desenvolvimento iterativo e incremental, que possui duas dimensões: o eixo horizontal e o eixo vertical. O eixo horizontal representa o tempo e mostra as fases (iniciação, elaboração, construção e transição) do projeto. O eixo vertical é constituído pelas disciplinas de: modelagem do negocio, requisito, análise e projeto, implementação, teste e implantação, além das atividades de gerenciamento de projeto, de configuração e do ambiente. Cada uma das fases do RUP é constituída por iterações e foca em uma ou mais disciplinas.
As metodologias supracitadas seguem processos orientados a documentação e, portanto, são consideradas metodologias pesadas. As metodologias ágeis visam reduzir esta carga na documentação, tornar o processo de desenvolvimento mais flexível e menos burocrático. Duas metodologias ágeis se destacam: XP e Scrum.
A Extreme Programming (XP) é uma metodologia ágil para pequenas e médias equipes que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Dentre as principais diferenças da XP em relação às outras metodologias estão: o feedback constante, a abordagem incremental e a comunicação entre as pessoas. De acordo com as práticas do XP, a construção do software deve ser padronizada, em pares, e realizada à medida que os requisitos surgem. Entre os desenvolvedores deve existir o espírito de propriedade coletiva, ou seja, o código do projeto pertence a todos os membros da equipe. Neste processo, o cliente deve está sempre presente para sanar dúvidas de requisitos, evitando assim atrasos e até mesmo construções erradas.
O Scrum é uma metodologia ágil de desenvolvimento e gerenciamento de projetos de destaque atualmente. Ela estabelece um processo de desenvolvimento iterativo e incremental, podendo ser aplicada no gerenciamento de qualquer atividade. Ele define conjunto de regras e práticas de gestão para alcançar o sucesso dos projetos como, por exemplo, o trabalho em equipe e comunicação melhorada. Em um projeto Scrum, dois papéis são fundamentais: o Scrum Master (SM) e o Product Owner (PO).
O SM é responsável pela aplicabilidade das práticas do Scrum no projeto, enquanto o PO representa os interesses do cliente no projeto. O ciclo de vida do Scrum inicia com a definição do Product Backlog. Este consiste de uma lista de itens, priorizados pelo PO, que precisam ser executados no projeto. Antes de cada iteração é realizada a Sprint Planning, uma reunião de planejamento da Sprint na qual são selecionados itens do Product Backlog que irão compor o Sprint Backlog.
Uma vez definido o Sprint backlog, a Sprint é iniciada. Uma Sprint é um esforço de 2 a 4 semanas da equipe para desenvolver as funcionalidades descritas no Sprint backlog. Ao final de cada Sprint, as funcionalidades concluídas são apresentadas e o funcionamento da Sprint é avaliado a fim de melhorar o processo para próxima Sprint. O Sprint é encerrado com um incremento do produto. Quando todos os itens do Product backlog forem atendidos, o produto estará completo e o ciclo se encerra.
Independente da metodologia de processo de desenvolvimento de software utilizado e do tamanho do projeto, uma disciplina de extrema importância é a engenharia de requisitos (ER).
Um requisito, de maneira geral, define uma função específica do sistema (requisitos funcionais) ou uma determinada restrição do mesmo (requisitos não funcionais) tais como desempenho, portabilidade, usabilidade, uso de recursos, entre outros. A ER define modelos, métodos, técnicase ferramentas para realizar cada das suas cinco fases fundamentais: elicitação, análise, documentação, validação e gerenciamento de requisitos.
Na fase de elicitação são reunidas informações sobre o domínio de aplicação, as funcionalidades do sistema e as restrições operacionais por meio de técnicas como, por exemplo, a etnografia, a entrevista, o cenário e a prototipação. As principais fontes de informação para a elicitação de requisitos são: a documentação, os stakeholders (todos os interessados no produto) e as especificações de sistemas similares. Após a elicitação, os requisitos devem ser analisados. Na etapa de análise, os requisitos funcionais e a lista de stakeholders deverão ser detalhados, os requisitos não funcionais serão classificados por categorias (performance, usabilidade, segurança, entre outros) e os riscos deverão ser mitigados através de um plano de redução de risco. Isso tudo dará origem ao produto final desta etapa, que é o documento de requisitos
Após a documentação, os requisitos devem ser validados para garantir que os requisitos definem o sistema que o cliente realmente deseja. Este é o melhor momento para se encontrar falha de requisitos, uma vez que o custo de uma falha desta categoria durante a implementação normalmente é alto. A validação de requisitos pode ser efetuada por meio de revisões regulares, prototipação e geração de casos de teste. A qualquer momento que uma mudança de requisitos é solicitada, o gerenciamento de requisitos deve planejar e gerenciar tal mudança.
Para isso, esta atividade define técnicas de rastreamento e controle de mudanças. O rastreamento de mudanças é normalmente implementado por meio de tabelas de rastreamento. Estas tabelas descrevem quais funcionalidades serão afetadas com as mudanças de requisitos, possibilitando mensurar o impacto de tais mudanças e, consequentemente, fornecendo subsídios para seu planejamento.
Outro ponto importante no processo de desenvolvimento de software é a qualidade. A gerência de qualidade visa garantir que requisitos de qualidade tanto do ponto de vista do cliente (robustez, eficiência, confiabilidade, usabilidade, etc.) quanto do desenvolvedor (manutenibilidade, reusabilidade, evolutibilidade, etc.) sejam atingidos. A qualidade do produto desenvolvido é influenciada pela qualidade do processo de produção. Para garantir a qualidade do processo de produção e, consequentemente, do produto, a gerência de qualidade deve estabelecer procedimentos e padrões.
Dentre os modelos de referência existentes, pode-se citar: a ISO/IEC 9126, a ISO9000, a ISO9001, a ISO/IEC12207. A ISO9001 descreve um modelo de garantia de qualidade em projeto, instalação, desenvolvimento, produção e assistência técnica. Esta norma pode ser aplicada especificamente na área de desenvolvimento, fornecimento e manutenção de software por meio dos roteiros descritos na norma ISO 9000-3. A ISO/IEC 9126 descreve as características de um software de qualidade. Estas normas apenas descrevem modelos de referência, é importante utilizar métricas para mensurar o nível de qualidade como, por exemplo, a quantidade linhas de código no software, o ponto-de-função e o número de pessoas por mês para desenvolvimento de componentes.
Uma maneira de medir a qualidade do processo é avaliar o nível maturidade da organização no que diz respeito ao processo de desenvolvimento de software. O CMMi é um modelo de referência, composto por cinco níveis de maturidade, que estabelece um modelo único de processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI emite certificados de maturidade para as empresas, que utilizam este como um diferencial no mercado.
Entretanto, o alto custo e os longos prazos para obtenção de uma certificação de maturidade CMMi impossibilitavam empresas de pequeno e médio aderir a este modelo. Diante deste cenário, surgiu no Brasil o MPS BR, um modelo de referência que se baseia nas melhores práticas de engenharia de software e é compatível com o CMMi. Este modelo possui 7 níveis de maturidade, tornando a implantação mais gradual e adaptada a realidade das empresas brasileiras.