Engenharia de Software

O software pode ser considerado como um artefato virtual que compreende as soluções que foram concebidas de acordo com os requisitos. Este artefato virtual é uma entidade abstrata que existe na mente dos usuários quando eles estão interagindo com o software. Esta entidade virtual é o modelo conceitual do software. Este modelo determina quais conceitos (ou objetos virtuais) estão presentes no software, quais as funções (ou tarefas) que o usuário pode utilizar –funcionalidade – e como ele pode interagir com o software – interatividade . Este modelo também é conhecido como metáfora da aplicação. Por exemplo, num editor de texto, como o MS Word, temos diversos conceitos que permitem ao usuário entender como está estruturado um documento e o que ele pode fazer com ele. No Word, encontramos os conceitos de página, bordas de página, margens, parágrafos, recuos de parágrafos, espaçamento entre linhas, distância-da-primeira-linha, distância-antes-do-parágrafo, tamanho da letra, estilo da let

A atividade de design de software ainda é uma das mais mal compreendidas da engenharia de software. Muitos utilizam o termo para referir-se a definição de “como” o software ser desenvolvido em contraste como a definição do “que” o software deve fazer – determinado pela especificação dos requisitos. Design de software também é utilizado como sinônimo de arquitetura de software. No entanto, a arquitetura do software, no sentido proposto na década de 90, como sendo a estrutura e o comportamento do software em termos de unidades abstratas interconectadas entre si – componentes e conectores – é apenas um dos produtos do design de software. Na nossa visão, design é mais do que isso. Design é a atividade de criar, idealizar ou conceber o software. O resultado disso precisa ser expresso através de modelos ou protótipos do software. O design visa apresentar uma solução que satisfaça a especificação de requisitos (funcionais e não-funcionais), definindo o que precisa ser implementado. Este conc

Modelos são essenciais em qualquer atividade de engenharia. O software, por ser um artefato invisível e conceitual, mas do que qualquer outro artefato, precisa ser construído com base em modelos. Existem diversos tipos de modelos de software, cada um deles proporcionando visões e níveis de abstração distintos. Diagramas são a forma mais utilizada de modelagem na engenharia de software. Um protótipo também é um tipo de modelo de software que vem sendo utilizado para apoiar diversos métodos de desenvolvimento. Modelos de software são construídos para uma visualização do sistema a ser construído, permitindo uma melhor compreensão e entendimento. Eles podem também ser utilizados para a especificação e para a documentação do software. O modelo quando utilizado para especificação possibilita uma descrição precisa do será desenvolvido pelos programadores. A documentação através de modelos deve refletir o que foi desenvolvido e será a base para as atividades de manutenção. De acordo com Booch,

Os cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir. Os cenários têm como foco as atividades que as pessoas realizam nas organizações possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido, explicando porque ele é necessário. Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar discussões e estimular novos questionamentos. Eles permitem também documentar o levantamento de informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos. Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os clientes e usuários envolvidos (muitas vezes de formação bastante heterogênea) que podem avaliar, criticar e fazer sugest

Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples é a decisão de requisitos de segurança mais restritos que podem ir de encontro ao requisito de melhor desempenho. A importância e complexidade de todas as atividades relacionadas aos requisitos levaram, no início dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida. Os objetivos d

Vimos que o software é parte de um sistema computacional mais abrangente e que a Análise de Sistemas é a atividade de identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado o escopo do software, os requisitos do software devem ser definidos e especificados. O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido. O que são requisitos? Requisitos são objetivos ou restrições estabelecidas por clientes e usuários que definem as suas diversas propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software. Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve pos

Agora que já conhecemos o processo de estimativas e algumas das métricas utilizadas, vejamos um exemplo de como podemos realizar o planejamento. A figura a seguir mostra uma visão geral do planejamento. Com base no modelo de processo de software podemos definir as atividades que precisam ser realizadas. Estas atividades devem ser organizadas em uma estrutura de divisão do trabalho (WBS - Work Breakdown Structure). Para cada uma das atividades estão definidos os artefatos resultantes e podem ser realizadas estimativas de tamanho destes resultados. Por exemplo, o número de linas de código fonte de uma atividade de codificação ou o número de elementos de diagrama em uma atividade de modelagem. Com as atividades definidas, pode-se montar a equipe de software . Dados históricos podem indicar as estimativas de produtividade dos membros desta equipe nas atividades definidas no WBS. As estimativas de tamanho do software podem ser utilizadas para o cálculo das estimativas de esforço para cada a

Várias métricas podem ser utilizadas na elaboração de estimativas. As mais utilizadas são: o tamanho do software, a produtividade dos desenvolvedores, a taxa de defeitos e o esforço humano. Linhas de código fonte Uma das métricas mais comuns para software é o número de linha de código fonte (LOC – lines-of-code, em inglês). As linhas de código são, de fato, um resultado imediato da atividade de desenvolvimento do produto final. No entanto, ela não considera diretamente, diversas outras atividades envolvidas, como requisitos, arquitetura, testes e outras. Alguns autores consideram que estas atividades estão implicitamente consideradas, ou seja, para se produzir um certo número de LOC, livre de defeitos, utilizando um certo processo de software, é necessário especificar os requisitos, projetar e modelar a arquitetura e testar o código, por exemplo. Linhas de código têm a vantagem de ser uma métrica bastante objetiva. Basta analisar o código e se tem o valor do que foi produzido. Es

As estimativas do produto e do processo são a base para o planejamento do projeto de software. As estimativas fornecem dados que permite prever a quantidade de pessoas que serão necessárias, o tempo necessário e os custos do projeto. Não é possível elaborar cronograma e orçamento sem o uso de estimativas. É importante ressaltar que os diversos elementos do planejamento estão relacionados entre si. Por exemplo, um dos maiores impactos nos custos de um software são os recursos humanos. Normalmente, um desenvolvedor ganha um salário mensal tornado este custo diretamente proporcional ao tempo de desenvolvimento. Para determinar o tempo de desenvolvimento é necessário estimar a duração das atividades do software. Estimativas da duração do software dependem do tamanho do software que é necessário produzir e da produtividade dos desenvolvedores. Estimativas são realizadas com base em métricas. Métricas de tamanho, duração, produtividade e esforço estão entre as mais utilizadas. Para faz

Quase todas as atividades que desempenhamos precisam ser planejadas e gerenciadas. Atividades de engenharia requerem um planejamento cuidadoso. Normalmente, os produtos são complexos, com muitas partes envolvidas, e as atividades são realizadas por um grupo muito grande de pessoas. Na engenharia de software não é diferente. Um projeto de engenharia de software deve estar baseado em um planejamento para que se possa gerenciar adequadamente a sua realização. Planejamento Planejar é estimar quais as atividades deverão ser realizadas; quem deverá realizá-las; quando devem ser realizadas e finalizadas; e quanto elas deverão custar. Tudo isto requer a elaboração de estimativas em relação ao número e à dimensão dos artefatos, do número de pessoas necessárias, dos prazos e dos custos. Para isto, a atividade de planejamento deverá resultar: Na realização de estimativas Na elaboração da estrutura de divisão do trabalho (WBS – Work Breakdown Structure) Na definição da equipe e

A empresa de desenvolvimento de software mais poderosa do mundo não conseguiu entregar o seu produto dentro do prazo previsto. O Windows Vista tinha entrega prevista para março de 2006, mas acabou sendo entregue 10 meses depois. Os principais motivos foram problemas com a sua arquitetura e gerência de software. Estes problemas vêm, há anos, sendo descritos na literatura da Engenharia de Software. O código do Vista cresceu para o espantoso número de aproximadamente 50 milhões de linhas de código fonte e sua arquitetura tornou-se um caótico “spaghetti”. Uma arquitetura spaguetti é aquela na qual o código torna-se tão dependente de outras partes que o acompanhamento do fluxo de controle possui tantas idas e vindas de uma parte para a outra que fica praticamente impossível entendê-lo. Além disso, qualquer pequeno ajuste em uma pequena parte do sistema é imprevisível e pode desestabilizar o código, levando-o a um comportamento defeituoso. Os problemas e causas do código spaguetti foram diag

O método Programação eXtrema (XP, do inglês eXtreming Programming ) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a melhoria constante do código (re-trabalho). A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta é uma das características importantes para o método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação ativa. Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário . Uma metáfora é a transposição de um

O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata. Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc.

Um programa é uma descrição formal, isto é, ele é descrito por uma linguagem de programação cuja sintaxe e semântica são definidos formalmente. Apenas desta forma é que temos a garantia de que o programa será sempre executado da mesma forma pelo computador. O modelo Tranformação tem suas raízes na abordagem de métodos formais para o desenvolvimento de software. A idéia é que o desenvolvimento deve ser visto como uma seqüência de passos que gradualmente transforma uma especificação formal num programa. O passo inicial é transformar os requisitos informais numa especificação funcional formal. Esta descrição formal é então transformada numa outra descrição formal mais detalhada, e assim, sucessivamente, até chegar-se a programas que satisfaçam a especificação. Durante este processo de transformações sucessivas - chamado de otimização - as especificação formais produzidas podem ser executadas por um processador abstrato, permitindo uma verificação formal da sua validação antes mesmo que

O modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são: estudo de viabilidade análise e especificação de requisitos design da arquitetura Design detalhado codificação e testes de unidades integração e teste do sistema entrega e instalação manutenção Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente. Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades clarame

O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que é prototipação (ou prototipagem). Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído. Objetivos da Prototipação Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação: Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória

Vimos que a engenharia de software requer que as atividades para desenvolver o software sejam feitas de forma planejada, gerenciada, com pessoal capacitado, custos e prazos estimados e utilizando teorias, métodos, técnicas e ferramentas adequadas. Elaborar um processo de software significa determinar de forma precisa e detalhada quem faz o que , quando e como . Um processo pode ser visto como uma instância de um modelo de processo ou método com suas técnicas e ferramentas associadas. O processo é definido durante a etapa de planejamento, no qual as atividades que o compõem foram alocadas aos membros da equipe de desenvolvimento, com prazos definidos e métricas para se avaliar como elas estão sendo realizadas. Enquanto um método é algo teórico, o processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos. O processo é o resultado do planejamento e precisa ser gerenciado no decorrer de sua execução. Não é objetivo deste texto a elaboração

O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum. O conceito de ciclo de vida de um software é muitas vezes confundido com o de modelo de processo (assunto do próximo artigo). Existem várias propostas e denominações para as fases do ciclo de vida de um software. Nossa proposta identifica 4 fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas. Essas fases são: Definição Desenvolvimento Operação Retirada Fase de Definição A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas . Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas