Scielo RSS <![CDATA[Journal of the Brazilian Computer Society]]> http://www.scielo.br/rss.php?pid=0104-650020060004&lang=en vol. 12 num. 3 lang. en <![CDATA[SciELO Logo]]> http://www.scielo.br/img/en/fbpelogp.gif http://www.scielo.br <![CDATA[<B>Letter from the Guest Editors</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400001&lng=en&nrm=iso&tlng=en <![CDATA[<B>The past, present, and future of experimental software engineering</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400002&lng=en&nrm=iso&tlng=en This paper gives a 40 year overview of the evolution of experimental software engineering, from the past to the future, from a personal perspective. My hypothesis is that my work followed the evolution of the field. I use my own experiences and thoughts as a barometer of how the field has changed and present some opinions about where we need to go. <![CDATA[<B>The marginal value of increased testing</B>: <B>an empirical analysis using four code coverage measures</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400003&lng=en&nrm=iso&tlng=en This paper presents an empirical comparison of the growth characteristics of four code coverage measures, block, decision, c-use and p-use, as testing is increased. Due to the theoretical foundations underlying the lognormal software reliability growth model, we hypothesize that the growth for each coverage measure is lognormal. Further, since for a given program the breadth and the depth of the different coverage measures are similar, we expect that the parameters of the lognormal coverage growth model for each of the four coverage measures to be similar. We confirm these hypotheses using coverage data generated from extensive testing of an application which has 30 KLOC. We then discuss how the lognormal coverage growth function could be used to control the testing process and to guide decisions about when to stop testing, since it can provide an estimate of the marginal testing effort necessary to achieve a given level of improvement in the coverage. <![CDATA[<B>Which documentation for software maintenance?</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400004&lng=en&nrm=iso&tlng=en Software engineering has been striving for years to improve the practice of software development and maintenance. Documentation has long been prominent on the list of recommended practices to improve development and help maintenance. Recently however, agile methods started to shake this view, arguing that the goal of the game is to produce software and that documentation is only useful as long as it helps to reach this goal. On the other hand, in the re-engineering field, people wish they could re-document useful legacy software so that they may continue maintain them or migrate them to new platform. In these two case, a crucial question arises: How much documentation is enough? In this article, we present the results of a survey of software maintainers to try to establish what documentation artifacts are the most important to them. <![CDATA[<B>Experiences tracking agile projects</B>: <B>an empirical study</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400005&lng=en&nrm=iso&tlng=en In this article, we gather results from several projects we conducted recently that use some kind of agile method. We analyze both academic and governmental software development projects, some of them using agile methods since the beginning and others in which agile methods were introduced afterwards. Our main goals are to classify the different projects, and to analyze the collected data and discover which metrics are best suited to support tracking an agile project. We use both quantitative and qualitative methods, obtaining data from the source code, from the code repository, and from the feedback received from surveys and interviews held with the team members. We use various kinds of metrics such as lines of code, number of tests, cyclomatic complexity, number of commits, as well as combinations of these. In this article, we describe in detail the projects, the metrics, the obtained results, and their analysis from our main goals standpoint, providing guidelines for the use of metrics to track an agile software development project. <![CDATA[<B>A case study applying process and project alignment methodology</B>]]> http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002006000400006&lng=en&nrm=iso&tlng=en Software Process Improvement (SPI) is one of the main software development challenges. However, SPI standards and models (CMMI, SPICE) have not been always adopted with success. The current problem is a lack of strategy to implement successfully these standards and models. To undertake this objective is essential observe real life experiences and detect process and project mutual relationships. Without this alignment it will not be possible to find out how process management is really important to achieve organization's strategic objectives. This paper proposes a methodology that allows the definition, evaluation and improvement of an organization software development process. This proposal, called a Process and Project Alignment Methodology (ProPAM), allows the specification of an organization development process, as well process and project alignment. ProPAM presents the following life cycle: (1) process definition; (2) project definition considering a base process model; (3) project coordination and monitoring and (4) process improvement assessment. This paper also provides an overview of the action plan to be taken within the software organizations that intent to conduct a SPI initiative. This plan includes two distinct phases: (1) specify the development process and (2) analyze projects, starting an SPI effort. In order to evaluate ProPAM, a study case is undertaken. The case study is performed following the action plan and presents all the steps of the ProPAM. Final results show that, when the organization started using ProPAM, process and project alignment reduced project planning time and effort. ProPAM also introduced new organizational practices that result in a SPI program.