The Latest
|
White Paper: Code Coverage: Ensuring Quality[article] Code coverage is an important measurement in software quality engineering. While software testing ensures correctness of the applications, a metric is required to track the completeness and effectiveness of the testing undertaken. Code coverage helps achieve reliable quality through identifying untested areas of the application. It is still a challenge to identify the right code coverage tooling solution. The next challenge lies in formulating the strategy for deployment of the tool and the process. This paper discusses code coverage tooling solutions and deployment strategy for quick benefits. |
||
|
Tips and Tricks From the Automatic Dependency Generation Masters[article] Make's dependency syntax is flawed because it incorporates both foo.o must be updated if header.h, system.h or foo.c are changed and foo.o is the result of compiling foo.c. Thus, anything to the right of the : is a prerequisite, but the first prerequisite where there's a rule body (i.e. commands) is special: it's the prerequisite that will be passed to the compiler (or other command) to actually generate the target. |
||
 |
Reloadable Test Data-O-Matic[magazine] Reloadable test data takes more time up front (as compared to on-the-fly data creation), but saves blood, sweat, and tears in the long term. It also virtually eliminates "works on my machine" bugs, creates a more intricate and realistic environment, and is the first step on the road to test automation. |
Tanya Dumaresq
February 26, 2009 |
|
Off the Trails[magazine] A focused approach toward testing a product is important, but sometimes we discover information that we didn't anticipate at all. One of the key skills in testing is dynamically managing our focus; sharpening it sometimes and widening it at other times. If we vary our approaches, we might find something surprising and broaden our coverage. |
||
|
The Missing Measurement[magazine] In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements. |
||
 |
Building a Foundation for Structured Requirements: Aspect-Oriented Requirements Engineering Explained (Part 2)[magazine] Aspect-oriented requirements engineering (AORE) is a new methodology that can help us to further improve the analysis, structure, and cost of development of software requirements. The second part of this two-part series focuses on the AORE specification techniques. |
Yuri Chernak
February 26, 2009 |
 |
Lean Portfolio Management: Guiding IT Projects with Business Value[magazine] Improving your software development process is only valuable if it fills the highest priority needs for your business clients with speed and quality. Lean principles provide guidance on how to create a structure that lets business priorities drive the selection of the right products for creation and enhancement. |
Guy Beaver
February 26, 2009 |
 |
Taming the Headless Beast: A Proven Strategy for Testing Web Services[magazine] The benefits of Web services are becoming widely demonstrated and accepted. However, these benefits are not without their own challenges. How can you enter data and verify the response of a system without a GUI? Are you ready to tame this headless beast? |
|
 |
Go, Team![magazine] Fed up with good-ol'-boy salesmen, a manufacturing mindset, and just-get-it-out-the-door directions? A little assertiveness, a few ounces of patience, a dash of charm, a lot of leadership, and some attitude adjustment by everyone might help. Read how one manager made the world a better place to work one small victory at a time. |
|
 |
The Ghost of a Codebase Past[magazine] Revisiting your old code can be an enlightening experience. Pete Goodliffe encourages us to look back at our old code to see how our technique has improved, how our programming skills have progressed, and what we can learn from it. |
|
|
Culture, Methods, and Governance and Their Impact on CM[article] Most professionals in the software development industry recognize the need for Configuration Management (CM). CM has been around long enough for people to have experienced problems when CM was either not in place or when the level of CM was insufficient for the needs of the work. CM values of identification, control, audit, and report are meant to ensure integrity of the product under development. These days, almost everyone has, at least, version control practices which include a version control tool and a simple checkout/checkin process. However, as with any engineering discipline, the level of the CM implementation (since CM is much more than just version control) will depend greatly on the culture along with the methods and governance that exist within the company. |
||
|
The Lessons Learned – Worst Mistakes Ever Made[article] Of all the questions you could ask a person, asking them to recount the 'worst mistakes' they have ever made might be one of the touchiest. However, that uneasiness might be all the more reason TO ask. In his book, Success through Failure, Henry Petroski explores failure as being essential to learning and ultimately, success: thus debunking the model that only 'success breeds success.' |
||
|
Five Mistakes a Company Can Make When Using Configuration Management[article] Joe Farah details five mistakes a company can make when using configuration management (CM). Until we start to admit to our mistakes and strive to reach the next generation of CM, we'll stagnate. |
||
|
Is Statistical Process Control Applicable to Software Development Processes?[article] Statistical Process Control (SPC) has been an integral component of the Software Engineering Institute's (SEI's) maturity models for about nineteen years. This article describes an intellectual journey in which the primacy of SPC applied to software development processes is challenged. |
Bob Raczynski
February 20, 2009 |
|
|
Introduction to Multi-Stage Continuous Integration[presentation] A full, continuous integration build and test is a key component of most agile processes. Unfortunately, as systems grow in size through consecutive iterations, these builds can easily take thirty minutes or more. |
Damon Poole, AccuRev
|
Pages
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.