Comparison of Change Management Systems

More documents

Recommendations

Info

32 Software Engineering has a poor built-in notification mechanism (a little bit improved by TeamPlain), and a fixed and poor notification letter format; however, everything becomes much better if you use the accompanying web interface called TeamAlerts. • A sort of reporting (including search results and saved queries) presents in all of the compared systems (though I was complained of the constraints of Redmine’s built-in reporting). Thanks to web interface there is a capability to save reporting results as local HTML pages in almost all systems (except ClearQuest which web interface is built on “unsavable” Java applets). “Exotic” reporting featured include: Remine’s Atom (RSS) channels, and the ability to create agile custom reports by SQL Server Reporting Services directly connected to VSTS’ database. • Though source control integration is a doubtful advantage in a general case (particularly, when a change management system is accessible from the outside and is used by clients and customers), it is quite convenient for software developers (regarding linking recorded changes to source code versions and changes). Probably the most widespread source control system is Subversion (SVN) – that is why it is by default supported in Redmine and BugTracker.NET. However, when we used VSTS in one of our projects, we succeeded in integrating with Subversion as well. Meanwhile, ClearQuest insists on using its own (Rational) source control system, ClearCase. • All the described systems have the ability to add your own (custom) fields to artifacts (we did not used them practically only in BugTracker.NET). Known restrictions include: Redmine does not allow arithmetic operations over custom fields (at least, without developing plugins); BugTracker.NET allows only 3 custom fields that look like drop-down lists with predifined values. • The used database defines the infrastructural convenience (some database server may already be used in your intranet, while another may not) and particularly the total cost (Total Cost of Ownership, TCO) of the change management system (because proprietary database servers may cost much more that the system itself, especially if it is free). The leader by the number of supported database servers is ClearQuest; practically we used only SQL Server among the listed. By the way, SQL Server is the most popular among all database servers supported by the four change management systems. VSTS is “hard-coded” to use the “heavy” SQL Server while BugTracker.NET, as far as I know, can work with the free SQL Server Express. Redmine is the leader by the number of free database servers supported. That’s all folks! Didn’t you expect I would tell you the global conclusion? :-) No, the conclusion is quite simple: everything depends on the context, i. e. the choice depends on the specific tasks, team members and, of course, the budget!.. Although I mentioned the budget only now, in fact in most cases it defines the selection of a system (by the way, not only a change management system).
Software Engineering Product Qualities Approach, Agile Style basic intermediate advanced About the author: Ryan Shriver is a Managing Consultant with Dominion Digital, a Virginia-based process and technology-consulting firm. Based in Richmond, he leads the IT Performance Improvement Solution which includes Agile Adoption, Agile Engineering, IT Process Improvement and IT Services Management. With a background in systems architecture and large-scale agile development, Ryan currently focuses on measurable business value and systems engineering. He writes and speaks on these topics in the US and Europe, posting his current thoughts at theagileengineer.com. Ryan can be reached at rshriver@dominiondigital.com Introduction In many agile organizations, the product owner is responsible for setting the team’s priorities through the product backlog. Whether they want enhancements to in-house systems or shrink-wrapped products, product owners get input from customers and stakeholders to create product backlogs of prioritized features (or user stories). These backlogs contain functionality that can be estimated by developers and planned for releases. While there’s nothing wrong with this approach of functions-first planning, I have come to believe it’s short-sighted in that it doesn’t place product qualities on equal pairing with functions. Currently in the agile community, there’s a tendency to focus too quickly on user-centric functionality instead of product qualities that can deliver real stakeholder value, often very quickly. Product owners who understand and leverage product qualities cannot only delight customers, but also help them achieve their organization’s business objectives. This article provides a how-to for progressive change agents interested in delivering products that generate measurable business value for their customers and stakeholders. You’ll learn how product qualities differ from functions, how to identify the right ones, measure them and use improvements to drive business results. Along the way, I’ll demonstrate how to integrate an agile development processes such as Scrum. What are Product Qualities? Whereas functions describe what a product does, product qualities describe how well the product performs. This can be along an array of technical and business dimensions. • Technical dimensions refer to how well the system performs, often referred to as “non-functional requirements”. Common ones include availability, response time, throughput, storage capacity, security, maintainability and accuracy. • Business dimensions refer to how well value is delivered to the stakeholders- -the business results of the product. This includes market-facing product qualities important to paying customers as well as those related to operational objectives important to business sponsors. How long does it take to record a business event? How much training is required for new hires? How much will our efficiency improve with your product? This article primarily explores the business dimensions, but the Author: Ryan Shriver concepts are equally applicable to both, as you’ll see. Why are they important? In crowded marketplaces where competitors have almost identical functions, products that perform at higher quality levels differentiate themselves from competitors. They also tend to be sold based upon their value propositions rather than viewed as a commodity, thus resulting in higher profit margins for the seller. Performing at higher-quality levels also has the benefit of being recognized as a leader in your industry, something that can only help sales. For software, desired product qualities are commonly financially driven: increase revenues and reduce costs. Yet some product qualities can also have non-financial objectives such as customer satisfaction, net promoter score and team morale. Often, these nonfinancial objectives are important leading indicators of future financial results and are thusly important to consider. One organization that puts product qualities forefront in their product development approach is Confirmit. They sell marketing research software and report their products-focused approach is one of their keys to success. Another organization that markets using product qualities is Unica, the marketing software vendor. While I’ve never used their products, I do think they market quite well using product qualities aligned with their customer’s needs. These include generating higher sales, retaining more customers and reducing operating costs. Notice these product qualities aren’t features 33
Page 1: Engineering Productivity: Some ways
Page 4 and 5: 04 Welcome Editor’s note Quarterl
Page 6 and 7: 06 Management Agile software develo
Page 8 and 9: 08 Management driven development—
Page 10 and 11: 10 Management for are developing. O
Page 12 and 13: 12 Management Important factor here
Page 14 and 15: 14 Management behavior. They all lo
Page 16 and 17: 16 Management Figure 2 - Buffer man
Page 18 and 19: 18 Quality in Project Productivity
Page 20 and 21: 20 Quality in Project Engineering O
Page 22 and 23: 22 Quality in Project For example i
Page 24 and 25: 24 Quality in Project measure of en
Page 26 and 27: 26 Quality in Project Figure 1 What
Page 28 and 29: 28 Quality in Project early complet
Page 30 and 31: 30 Software Engineering Comparison
Page 34 and 35: 34 Software Engineering or function
Page 36 and 37: 36 Software Engineering Let’s loo
Page 38 and 39: 38 Software Engineering What’s fu
Page 40 and 41: 40 Software Engineering Note, unles
Page 42 and 43: 42 Software Engineering Usability.I
Page 44 and 45: 44 Software Engineering Figure 11 A
Page 46 and 47: 46 Software Engineering cyclical le
Page 48 and 49: 48 Software Testing motivating if t
Page 50 and 51: 50 Software Testing This concept of
Page 52 and 53: 52 Software Testing defects, or the
Page 54 and 55: 54 Software Testing 5. A Critical M
Page 56 and 57: 56 Software Testing Equivalence par
Page 58 and 59: 58 Software Testing little more com
Page 60 and 61: 60 Software Testing Good, now let
Page 62 and 63: 62 Software Testing an important pa
Page 64 and 65: 64 Software Testing the software de
Page 66 and 67: 66 Software Testing Five Types of R
Page 68 and 69: 68 Software Testing Figure 2 A typi
Page 70 and 71: 70 Software Testing Figure 4 Typica
Page 72 and 73: 72 Software Testing Confrontation o
Page 74 and 75: 74 Software Testing Quality Managem

Comparison of Change Management Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?