Requirements elicitation can present a variety of challenges. Visualization tools that allow for working simulations are now being used to help facilitate communication and collaboration in requirements gathering. SearchSoftwareQuality spoke with David Nyland, President and CEO of Blueprint Software, to find out more about visualization software and its use in the software community.
Q. What are visualizations?
Nyland: Visualizations in the context of requirements is the bringing to life the requirements in a visual way. This allows people to interact with all aspects of the requirements, allowing them to see, touch and feel them rather than reading a very monolithic-type document.
Q. Might this approach put too much emphasis on the User Interface?
Nyland: It’s very important for the UI to be visualized in context with all the other requirements. UI visualizations alone don’t tell the full story.
Q. If you were doing a simulation, how would stakeholders be able to review those requirements that can be seen?
Nyland: It could be a combination of business process walk-throughs with traceability detects and functional decomposition of lists containing text with all traceability exposed.
Q. Do you think this method of gathering requirements might replace more traditional methods?
Nyland: I think in the foreseeable future, a requirements document will always exist; however the process to get that document can be done differently. Visualizations and simulations and validation of requirements can be done first and used to then create the requirements document.
Q. So can the document be created from the visualizations with screen shots of the UI, for example?
Nyland: Exactly. It can be one or many documents. The information can be integrated or separate depending on the audience. It will be the same information that was validated visually, automatically transferred into templates for the customer’s organization.
Q. Are we shifting the responsibility of the design? Are the developers and architects involved? Is it too much design work up front?
Nyland: We find that the role of the business analyst and the process of creating requirements is done earlier in the process than design, so the early UI definition is low fidelity with emphasis on functional definition and not on the rich design. Downstream the designers take over. Once the designers do take over, we want to capture that information and bring it back so we can enrich the requirements.
Nyland: Some of our customers update the requirements as things change.
Q. Do customers have unrealistic expectations about what they’re seeing in terms of the UI and timeframe?
Nyland: Most of our customers have a lot of early, positive interactions because they’re contributing. There’s a sense of relief that the system is properly validated and that the system will meet the requirements. The key thing is they can see all the changes as part of the review. They see all the requirements, beyond the UI, so they can see all the complexity and detailed requirements.
Q. Are the developers involved in the early processes?
Nyland: It tends to be the architects and development leaders who are involved early. Once the requirements are approved, the developers have access in paper form or can run a simulation. Particularly in instances with off-shored development, using a rich simulation rather than reading a document makes a tremendous difference to developer context and productivity.
Q. What challenges are you finding with this approach?
Nyland: Getting the message out that this exists. It’s relatively new.
Q. What do business analysts think?
Nyland: It’s change and change is always difficult. With some training and pilot projects we find most organizations pick up use of the tool quickly and see the benefits.
Q. How difficult is it to build the simulations?
Nyland: Without simulations, business analysts may use a tool like Visio to describe requirements. The key approach for the vendor community is to develop editors or methods of capturing data that are very similar to the way people author documents; but the net effect is that it’s going into a system that can be verified, validated, and most importantly, it can be simulated.
Whether I’m trying to estimate how long it will take to do a house project or a software development project, estimation is a whole lot easier if you’ve done a similar task to the task you’re trying to estimate. Once you have a baseline, you not only have gained skills in accomplishing that task, you can use the data from that first “iteration” to help you estimate the time it will take to do similar tasks.
In Chris McMahon’s recent tip, How Agile estimation works, he talks about assigning points for user stories. He gives an example of adjusting over time based on the accuracy of the estimations for each iteration. Early in the development cycle, it may be more difficult to accurately estimate what it will take to deliver the stories. Over time, the team will become more experienced and will have a better idea of what they can actually accomplish with each iteration so their estimations will become more accurate.
Lyssa Adkins, in her new book, Coaching Agile Teams, also makes this point when she describes one of the differences between traditional project management beliefs versus agile beliefs. In traditional project management, “the plan gets more accurate over time as we flesh out the project through phases of activity: requirements, design, development, testing, and so on.” This is replaced with the agile belief, “a plan gets more accurate over time because it is constantly revised and trued up to the team’s actual performance.”
Mike Cohn also spoke about this not too long ago at a Denver Agile User Group meeting. You can read about it on our blog: Mike Cohn on estimating software in Agile environments.
Today, agile ALM vendor ThoughtWorks Studios announced a “continuous delivery” product, Go. Go is an upgrade from ThoughtWorks’ Cruise product and is used in conjunction with Mingle for project management and Twist for automated testing to create what Thoughtworks calls an “end-to-end, adaptive ALM solution.” The idea is to integrate agile practices throughout the enterprise. Tight collaboration exists, not just between business and development, but also between development, QA and IT Operations.
I spoke with Thoughtworks Studios’ managing director, Cyndi Mitchell, about the announcement. “Tools that were appearing for agile were prescriptive,” she said in talking about the history of ThoughtWorks. “We wanted to build a new generation of tools for the agile market. We launched Mingle and Twist. ” And now, she says the next wave of agile is something they’re calling “continuous delivery.”
Theresa Lanowitz, analyst and founder of voke inc., has this to say:
The products ThoughtWorks Studios is creating are organic and strive to solve very specific problems. The most recent product, Go, is an evolution to what Cruise is. Go is focused on continuous delivery vs. Cruise on continuous integration.
Go is attempting to solve some of the most egregious problems in the application lifecycle, namely the breaking down of entrenched silos between development, quality assurance, and operations and deliver value to the line of business. Enhancing the collaborative experience between the line of business, development, quality assurance, and operations is positive. Go also stresses that releases are tied to business needs and objectives vs. operational constraints.
Jez Humble, who co-authored the upcoming book, Continuous Delivery, with David Farley, explained that continuous delivery involves going beyond iterative builds and including capabilities to automate the deployments. “You need to automate the build, test, and release process. We need to bring development teams, QA, and IT Operations together throughout the lifecycle,” he said.
As an example, the Environments feature in the Go product will allow for viewing which application is in each environment as well as performing one-click deployments.
Agile Application Lifecycle Management (ALM) vendor Rally Software announced its acquisition of Rally for the iPhone from Blue Hole Software yesterday. Formerly selling for $15 under the application name of ScrumAway, the iPhone app is now free and rebranded as “Rally for the iPhone.”
In April of this year, Rally acquired AgileZen, taking advantage of emerging Kanban, and now this acquisition is extending Rally’s further into the mobile world.
I spoke with Todd Olson, product line manager from Rally, who said:
“It’s part of meeting emerging demands from our customers to have more mobile access to Rally. The reality is many people simply take their smartphones to meetings. They don’t need to take their laptops to meetings because their phones are becoming as powerful as computers were three or four years ago.”
Asked about Rally Software becoming available on other smartphone platforms, Olson replied that there were no immediate plans, but more may be coming. This move, he said, was spurred by Blue Hole’s work on Rally’s open inversion APIs, and many other third parties now build plug-ins and connections to Rally. “We’re tracking the Android space carefully and evaluating various alternatives,” he said.
Being a person who likes to take advantage of free iPhone apps, I downloaded and installed the application. Installation was a cinch, but the first thing I needed to do was log in to an existing account. Well, Rally Community Edition is free for up to 10 users working on a single project, so I went ahead and went back to my desktop and signed up for that. Five minutes later, I was in the tool, setting up my profile, watching tutorials, and creating my first project.
I went back to my iPhone and, sure enough, there was my project, ready for updates. For a tool with a lot of features, I was impressed and amazed that this was all available for free. For all those people who are looking to become more experienced with agile development, this seems like a great opportunity. The tool came with plenty of video tutorials aimed at helping the newbie learn agile, learn how to transition to agile and learn the Rally tool.
That being said, the reviews from the iPhone application are currently showing an average of three out of five stars. With only eight reviews, it can hardly be considered statistically relevant. From the small sample size of reviews available today, it seems there are users from both sides of the fence. One satisfied user gives the app five stars and said: “Great for keeping up to date when out of the office – very easy to use – I like it!” Others give four stars, praising its ease of use when on the go. The two negative reviews were from users who are disappointed by the lack of functionality. The worst review calls the app “utterly useless” and claims the views and functionality are very limited.
Olson disagrees, of course, and points to the app’s powerful features. Customers who have not yet provided reviews via the app store have told him they like Rally for iPhone’s instant access and visibility into status of iterations and releases, as well as management features for requirement, backlog and even things like re-ranking.
“We’re absolutely watching the reviews and talking to customers aggressively,” said Olson. “Rally has a long history through our customer portal and community code agile commons of soliciting feature requests from our customer community, having them help us rank those and delivering in a timely fashion against that backlog.”
I checked to see what other iPhone apps might be available for agile PMs and found Scrum2Go for $1.99 and Agile Project Management with Scrum for $5.99. Neither of these had reviews. There may be others, but my quick search didn’t find anything free that would be comparable to Rally for the iPhone. ScrumAway is no longer available, so I could not find out what the app store reviews were from the product before it was acquired.
Coverity and Armorize are two fairly well-known names in the software industry. Coverity is known for its static source code analysis and Armorize is recognized for its security provisioning. As of today, the two have joined forces to provide the best of both world’s under one umbrella allowing static defect testing, security assessments and their resolutions to be implemented simultaneously and earlier in the SDLC.
“We had been working with Armorize for a while on some other projects,” said Andy Chou, Chief Scientist and co-founder of Coverity, “when we really started paying attention to them. They had this vision of bringing security testing and defect resolution in early and throughout the SDLC — an idea that makes a lot of sense but is rarely acted on.”
“One of the biggest problems I’ve seen in souce code security analysis is that companies are going about it wrong. They are forcing developers, many of which have no formal education in security, to deal with major security issues, finding defects they don’t fully understand, manage them and delete them. Our direction has always been to make security issues nearly invisible to developers, they shouldn’t be reaching outside of their comfort zone,” says Armorize CEO Caleb Sima, “security provisioning should be adapted around developers, so security defect detection comes online sooner and is less intrusive.”
Security departments are typically brought onboard to test an application late in the development cycle, meaning that many issues must be addressed and resolved on heavily-truncated timetables. As a result, vulnerabilities often pass through quality check points and enter the market under the guise of a polished application that is later found defective.
Defects after a release are vastly more expensive to repair after than during the development phase and often reflect poorly on a company’s public image. It might seem like a “no brainer” but most development teams continue to wait until the last second to get their applications secure, rather than making security efforts throughout.
So when and where should security planning really take place? “The future of software security is aimed at bringing in security testing and analysis early in the SDLC. Realistically, in the future, it could be brought in as early as the requirements phase, there isn’t a good reason why prepping for security can’t be done there,” says Sima.
“Many developers don’t have a firm grasp on security issues, which is why so many defects remain in released applications. There is a real disconnect between developers, testers and the security personnel on major software security issues. By bringing security testing to the forefront, we are hoping to spread awareness of these issues and make them less-prominent in today’s applications,” says Chou.
The Coverity/Armorize combination platform could be a nice fit for agile teams who work in sprints to get portions of an application tested for security before the entire application is built and prepped for its final testing. Having most security concerns settled prior to final testing should ease the strain on enterprise security testers, who are normally hindered by limited resources and time.
As reported in June, Coverity has built a database of common defects that also includes common fixes. The database was built into the Coverity 5 offering so when defects were found in applications, the Coverity defect database would identify them and recommend fixes. Coverity plans to offer a similar function on the security side with a database of security compromises, common causes for them and solutions. Their aim is to help developers practice strong coding habits and prevent these common issues from becoming reoccurring problems.
Like the defect database Coverity introduced, the Armorize addition will also prioritize potential issues using the same high priority, medium and low categorization. This will allow low concerns to be left on the back burner in favor of solving more dangerous vulnerabilities, hopefully saving time, effort and money as a by-product.
The final product is set to hit the market before the end of 2010.
While Apple’s famous (now possibly infamous) iPhone 4 continues battling with physical malfunctions, bad press and more recently lawsuits, Google has opened developer doorways into its Android Smartphone.
A new public offering called App Inventor allows just about anyone to become an application developer on the popular Android format which runs on a Google operating system. Google has been boasting incredible ease of use and availability to everyone all morning as reported on TechCrunch.com.
App Inventor uses predesigned templates (blocks as Google has identified them) to create numerous different applications using the popular WSIWIG format familiar throughout the internet. The application developing engine appears to cater primarily towards “fun apps” like games, socializing features, quizzes and other frivolous applications, so professional Smartphone app developers should continue to dedicate their attention to their proven development tools.
For more information on professional mobile application and Smartphone development, we recommend these stories:
Smartphone and personal device development challenges
Mobile apps for Smartphones and other devices are increasingly in demand in today’s enterprise.
Testing mobile applications: STAREast speaker suggests crowdsourcing
As mobile applications become business-oriented, the importance of test coverage becomes more apparent.
SQL injection flaw leaves door wide-open to valuable user information on a popular file sharing site
This week, a trio of hackers based out of Argentina uncovered various entry points into the popular (and controversial) file-sharing site Pirate Bay using SQL injection flaws contained in the site. The infiltration gained them access to upwards of four million user profiles containing names, addresses, email accounts and other sensitive and (potentially) incriminating information.
As originally reported by Krebs on Security, the group gained access through SQL injection vulnerabilities contained within the site. The leader of the hacker group, Ch Russo, maintains that he and his accomplices did not crack the site for any personal gain, though he did admit, once inside, it had dawned on him that some of the information uncovered would have been valuable to the Recording Industry Association of America and Motion Picture Association of America. But at the end of the day, they chose not to share information with either organization. The group says that they were only attempting to spread awareness that security vulnerabilities exist and SQL injection flaws can still be readily found in today’s applications and websites.
Pirate Bay is a website that allows registered members to access and download numerous types of multimedia using the currently lawful method of file sharing. File sharing takes particles of related information from various sources and then compiles them in sequence to create a full multimedia file.
Is it legal? Well that is for the courts to decide. If it is deemed illegal, it would a difficult crime to trace. Technically, downloading copyright material is unlawful but because the media is compiled from numerous sources it is very tricky to track and even harder to prosecute because only a portion of media is taken from each source. It would be like trying to charge someone for Grand Theft Auto who only stole a steering wheel.
Either way, the hack has eyebrows raised about the security exposure and concerns are growing because of SQL injection and other types of security flaws. This hack just proves what kind of damages are possible when SQL injection issues exist. In this case, under the assumption that file sharing will become illegal, these hackers could have sold information on users that might provide evidence for lawsuits. SQL injection flaws are clearly no laughing matter.
SQL injection is and has been a major concern among quality and security departments as it is elusive to developers and testers to find and eliminate but it is fairly easy for hackers to find and exploit. In this case the hackers (had they been malicious ones) could have exposed and sold valuable personal information of Pirate Bay users.
Hackers are able to gain access to apps through weak SQL portals by adding their own Structured Query Language (SQL) into language field features on sites and in applications. These coded statements instruct the app or site to respond to their coded request and (in most cases) grant them administrative or backend access. Once access is gained, typically the sky is the limit to what database information becomes available and what changes can be made.
While many vendors advertise SQL injection detection and fixes in their offerings, SQL injection remains a high-profile risk in many expert’s minds.
For information on how to protect your software applications and sites from similar security compromises, we recommend these tips:
- Application security checklist: Finding, eliminating SQL injection flaws
Seeking out SQL injection issues and entry-ways? This application security checklist shows ways to identify susceptible application areas and kill flaws.
- Quick attacks for Web security, penetration testing and SQL advisory
Are you in need of penetration testing but are on a strict budget? Expert Matt Heusser provides tips and tricks to get your software application live and without issues.
- Are SQL injection attacks really a big software security risk?
A software security expert separates vulnerability scanner vendor hype from the reality about injection attacks in this tip.
This month SSQ is focusing on software requirements and ways to overcome the challenges so that defects can be eliminated up front.
One method of requirements elicitation that I blogged about recently is the use of visualizations. Visualization software is used by business analysts to create a working simulation that can be used to help communicate with stakeholders when gathering requirements. This blog post sparked enough debate to motivate me to write a full feature story: Are visualizations the answer to gathering requirements? In this piece, I interview several project team members and analysts about their experiences with using visualization, exploring the benefits and drawbacks.
One of the biggest points of contention is the concern that visualizations will focus on the User Interface design, or on ‘how’ the software should work, rather than ‘what’ the software should do. Requirements expert Robin Goldsmith describes how to “discover REAL business requirements” in Problem Pyramid discovering REAL software requirements – Part 1.
I asked Goldsmith what he thought of introducing UIs as part of the requirements gathering process and in his expert response he answers rather adamantly, “Focusing on the UI, system use cases, prototypes, visualization, and other forms of product/system/software solution description in the name of requirements makes it virtually certain that the developers (which include analysts and testers as well as programmers) will not be paying sufficient attention to what is really needed.”
However, after talking to those who experienced such success with visualization software, my impression is that there can be a lot of benefit from introducing the UI at a high-level as a tool for communication and collaboration. In my opinion, if you don’t talk about these things with the stakeholders they are almost certainly going to end up with something they didn’t expect when the product is delivered.
What about you? What are your opinions and experiences?
Mike Cohn, one of the leading authorities on agile methodologies, just happens to live in Lafayette, CO, a Denver suberb. This is lucky for those of us that live in the Denver area because it means we occasionally get to see him speak at the Denver Agile User Group meetings. Such was the case last week when Cohn gave us a preview of the keynote he will be giving at this the Agile 2010 Conference being held August 9-13 in Orlando, FLA.
In his presentation, Cohn reminds of the progress that’s been made in agile. Though it’s not a silver bullet, organizations that are using agile have reported productivity improvements. “Agile is not something you become; it’s something you become more of, ” Cohn stressed. He then added, “For most of us, it’s about becoming more than we were.” Cohn challenged us to “raise the bar on each other,” finding ways to incrementally improve. “It’s still about continuous improvement,” he said. Cohn then talked about how we should be ADAPTing to agile with:
- Desire to Change
- Ability to work in an agile manner
- Promote early successes to build momentum and get others to follow
- Transfer the impact of agile through the organization so it sticks
Check out this video where Cohn tells us about ADAPTing to agile.
Over the holiday weekend YouTube users fell victim to a series of coordinated attacks by a team of black hat users. Their antics ranged from redirecting unsuspecting YouTubers onto malware sites to plaguing them with pop-up ads for adult Websites. The group used a little-known weakness in YouTube’s comment field to place poisoned HTML tags that caused the pop-ups to appear uncontrollably, eventually forcing Google (YouTube’s owner) to step in and shut down the comment features and other aspects of the site.
Allegedly, the attack was coordinated by an online team of pranksters known as the 4chan (pronounced Fortune). The group used a flaw in YouTube’s comment box that normally restricts the amount of HTML allowed, by simply adding additional script tags. Usually when these tags are used, YouTube denies the entry of script tags but 4chan members discovered that by adding, repeat secondary script tags that only the first ones were stripped out leaving the secondary tags intact and thus allowing the hackers to do their worst to viewers of YouTube’s most popular videos.
Over the past year, SearchSoftwareQuality has featured a number of tips designed to help enterprises test and prevent defects related to cross-site scripting (XSS) vulnerabilities. These tips describe professional ways to shut down and secure potential XSS problems from Internet hackers. Using these tips will help secure your enterprise applications from similar attacks and prevent online mischief as XSS vulnerabilities truly are realistic problems.
XSS testing and prevention tips
Cross-site scripting (XSS) explanation
Cross-site scripting issues are a type of validation weaknesses in a Web form. Though XSS issues can be fairly easy to fix, avoiding them all together is key.
Beating software’s cross-site scripting, authentication problems
Web security expert explains where security efforts are best placed. By checking for cross-site scripting and authentication mechanism weaknesses you can eliminate problems in your application.
Finding cross-site scripting (XSS) application flaws checklist
Cross-site scripting (XSS) is a major concern, it can be unpredictable and requires multiple tools to test for it. An expert sheds light on the history of XSS issues and recommends tools to prevent XSS application issues.