Fables

A Fable: The King's Companion

A Fable: Kingdom of Beal

Missing the point

    Example 1

    Example 2

 A Fable: The Fairy and the Pig

Interviewing Tools

Card Sorting

Web Page Test

Testing
Search for Zero Defect Software
Web Applications: Vulnerabilities and Security

From ACM's TechNews, March 15, 2004

"Watts Humphrey on Software Quality"
Computerworld (03/08/04); Anthes, Gary H.

The Personal Software Process (PSP) and the Team Software Process (TSP) are designed to show individual developers and their teams how to apply the principles of the Software Engineering Institute's Capability Maturity Model (CMM) in their work, according to Watts S. Humphrey in an interview with Computerworld magazine. Humphrey, a researcher at Carnegie Mellon University in Pittsburgh, wrote the first version of CMM for software in 1987, and developed PSP and TSP. He suggests that PSP and TSP were needed because the CMM framework only told engineers what to do. The best approach to PSP and TSP is to have a small group in a department use them for a couple of projects. Once the group understands how it works, it will be easier to gain more support from the organization and gain momentum for CMM. PSP and TSP offer productivity improvements between 70 percent to 80 percent, as well as 100-to-1 quality improvements in shipped code. Humphrey says the new Capability Maturity Model Integration (CMMI) product suite is more of a business solution that supports the overall organization, but he does not recommend moving up the old CMM ladder then switching to CMMI at Level 5. And he advises IT managers to focus more on making improvements in an orderly manner than on trying to get to Level 3 or Level 4, to gain the support of senior management, and to reward line managers with bonuses but also hold them accountable.

From ACM's TechNews, April 16, 2004

"Can Software Kill You?"
TechNewsWorld (04/13/04); Germain, Jack M.

Faulty software is becoming a larger concern now that computers are involved in nearly every aspect of people's lives. Bad code can even lead to deaths in some cases, such as at the National Cancer Institute in Panama, where 21 patients died in 2000 due to radiotherapy overdose, caused by improper programming. Software glitches have been behind major vehicle recalls in North America, some affecting critical safety functions such as brake warning lights. Yet according to the National Institute of Standards and Technology, software developers spend about zero percent of their development budget on code-checking and correction. While no software can be made perfect, a more responsible attitude can improve software quality, according to Cigital Labs CEO Jeffrey Payne. In fact, the Institute of Electrical and Electronics Engineers reported that simple peer review would eliminate 60 percent of all software bugs. Many software developers are wary of the cost of building better software upfront and instead rely on patching, says Christopher Nolan of application testing and monitoring firm Empirix. He says software that is used for applications other than originally intended also leads to failure. Quality assurance processes offer a way to drastically improve software quality, says Nolan. Companies should first conduct risk analysis and apply resources more effectively. Software testers are also important, and need to be able to think up extraordinary cases in which software might fail. Agitar CTO Alberto Savoia says computers can be used to improve software quality using testing applications. With the increase of available computing power, computers today can scan individual software modules before the entire code is run to ferret out bad code, he says. Click Here to View Full Article

From ACM's TechNews, March 22, 2004

"Why Software Quality Matters"
Baseline (03/04) Vol. 1, No. 28, P. 32; Gage, Deborah; McCormick, John; Thayer, Berta Ramona

Software errors that led to the deaths of Panamanian cancer patients from overexposure to radiation--and criminal prosecution against the technicians who used the software--illustrates the vital need to anticipate and remove glitches before they become a problem with potentially fatal consequences. Other deadly incidents attributed to buggy software include the 2000 crash of an Marine Corps Osprey tilt-rotor aircraft that left no survivors; the shooting down of friendly aircraft by the Patriot Missile System in Operation Iraqi Freedom; and at least three fatalities resulting from last summer's East Coast power outage. Among the reasons given for bad software is a flawed programming model, poorly thought-out designs, lax testing procedures, and the unpredictability of program interaction. The FDA distributes "guidance" documents suggesting that software manufacturers comply with generally-accepted software development specifications, keep tabs on design specs, and formally review and test the code they create--but without making any specific recommendations. The Panama incident is causing some industry experts to consider the possibility that more stringent regulation of software development is necessary. Observers note that not only are software development regulatory agencies few in number, but existing agencies such as the FDA do not go far enough to ensure quality software. For instance, the FDA approves products under either premarket approval or premarket notification. The former mechanism applies to dramatically unique technologies that are subjected to rigorous testing, while the latter applies to products that fit into existing device categories, and do not require FDA or corporate trials to be approved; the Multidata Systems International software responsible for the radiation overdoses in Panama was certified under the premarket notification process. SCC director William Guttman estimates that there could be 20 to 30 bugs for every 1,000 lines of code generated by corporate programmers or commercial software manufacturers. Click Here to View Full Article

From ACM TechNews, February 23, 2004.

"Unplugged: Charles Simonyi Creates Software Intentionally"
Tech Update (02/15/04); Farber, Dan

Intentional Software founder Charles Simonyi attributes most software problems to a gap between design intent and the actual coding, and cross training subject matter experts and programmers will not solve these problems. His solution is to move programming further upstream while preserving the design intent. In such a scenario, subject matter experts would present their ideas to programmers via PowerPoint, for instance, and the programmers would write a generator program in C# that reads the presentation and writes the program. The computer-aided design (CAD)-like program that the generator can read and process its input from will be provided by Intentional Software. Simonyi explains that writing generators will excuse programmers from the burden of redoing the same transformations each time the problem statement is modified or changed by the stakeholders, thus allowing the result of changes to be deployed in seconds instead of weeks and at vastly less expense--and free of deployment bugs, as well. The generators can be built and adjusted by coders in the same way that automated equipment can be adjusted by engineers and mechanics. Simonyi adds that though intentional programming does not reduce domain bugs, it facilitates rapid turnaround for fixes. The Intentional Software founder says, "With intentional software, there will be no limitation on the nature of the domain notation, and the implementation will be expressed in terms of a generator, which can be simply re-run if the design or implementation, or both, change." Simonyi notes that his company should roll out design tools and a generator interface next year. Click Here to View Full Article

From ACM TechNews, December 12, 2003.

"Why Software Quality Stinks"
CIO (12/01/03) Vol. 17, No. 5, P. 28; Surmacz, Jon

The poor quality of software can only be improved by the deployment of an effective software quality assurance (SQA) program, yet 38 percent of developers polled by the Cutter Consortium across more than 150 software development organizations report that their companies lack such programs, while 31 percent say they have no SQA personnel at all. Seventeen percent claim no software quality problems, while 36 percent say they do not address quality until the very end of the development cycle. Another 36 percent attest that their companies boast a SQA team that is closely involved in most (if not all) software development projects, 29 percent report the presence of integrated SQA team members in each project, and 25 percent remark that most or all projects are the responsibility of an SQA manager. Fifty-three percent of respondents indicate that their senior management believes the company's software quality is reasonable but should be improved; 30 percent say management considers the software to be of consistently high quality; 11 percent of developers note that senior management never discusses software issues with them, and 6 percent report that management is very dissatisfied with software quality. A five-step procedure for setting up an effective software quality team can be extrapolated from the survey's findings: First, getting senior management on the side of the SQA manager is critical. Second, a quality organization must be established with a manager "who has spent a few years in the trenches and has gotten products out the door," according to the Cutter Consortium's E.M. Bennatan. The three remaining steps include training developers as well as the quality assurance group, obtaining customer or user group feedback, and collating metrics to track software quality improvements.

From ACM News, October 6, 2003

"Buggy Software Taking Toll"
Orlando Sentinel (10/05/03); Cobbs, Chris

Software is increasingly pervasive in modern products, as are the glitches that inevitably show up in growing pools of code. Unlike relatively lithe programs that operated computers years ago, many of today's software programs have millions of lines of code; enhanced programming tools have enabled this productivity, but the test and debug tools used to check these products have remained mostly unchanged, according to Florida Institute of Technology computer science professor Cem Kaner. SRI International principal scientist Peter Neumann predicts the software bugs that inhabit these programs will have more impact on people's everyday lives in the future--a message Neumann has brought before Congress five times as an expert witness. Besides inconvenience, software bugs cost the U.S. economy at least $59.5 billion each year, according to a study by the National Institute of Standards and Technology. Neumann says one underlying reason software is so error-prone is because the marketplace rewards speed-to-market and functionality more than reliability, and he notes that software engineering is a still-developing art compared to other engineering disciplines such as building architecture and civil engineering. Defects in software programs are also embedded in numerous details, and their presence is not as obvious as a missing strut in a bridge, for example. Carnegie Mellon University associate professor Philip Koopman says the average high-end European sedan made today uses around 70 computer chips and is programmed with 500,000 lines of code, with an average error rate of one defect per 1,000 lines of code. In a car, some of these defects could have life-threatening consequences, while recent catastrophes caused by software errors include the crash of the Mars Polar Lander in 1999, where programmers mixed metric and standard measurements.

"Rethinking Software Testing"
Software Development Times (10/01/03) No. 87, P. 29; Rubinstein, David

Buggy software, products that fail to function as they are supposed to, and lost profits are the result of developers not testing their software until very late in the development process, and rushing through testing in order to get products out quickly. Many development proponents strongly agree that the development cycle, software production costs, and time-to-market can be significantly reduced when flaws are detected earlier. According to vendors and industry experts, the chief strategy is to move up testing to an earlier point in the development cycle, writing and testing code simultaneously being one example. Delaware North's Internet and Information Systems has chosen a different route by keeping software development and quality assurance testing separate, employing virtualization software to replicate the development environment for testers and cut hardware and software costs, not to mention reduce DLL conflicts and versioning difficulties. AutomatedQA's Robert Leahy reports that more developers need to conduct unit testing, and Peter Varhol of Compuware comments that developer/tester convergence requires new tools, while developers must become familiar with conducting static source-code analysis or unit tests before moving on to the next coding step. QACenter product manager Mark Eshelby believes that companies facing a tight product deadline can lower the odds of failures by identifying the highest areas of risk and testing them when the crunch comes, but says that automated tests are still an important component. He adds that 11th-hour code revisions can be made without dramatically affecting the test environment via the design of object-oriented test scripts and data-driven test automation. Click Here to View Full Article

From ACM News, September 19, 2003

"Testing Information Systems During Development Will Prevent Problems"
EurekAlert (09/16/03)

Penn State researcher Dr. Sandeep Purao has taken a systematic approach to applying the more than 350 existing metrics to object-oriented systems. Purao, associate professor of information sciences and technology, and co-researcher Vijay Vaishnavi, professor of MIS at Georgia State University, grouped the metrics that apply to any IT development project using the object-oriented approach and found gaps and overlaps in the stages of project requirements; design specifications; implementation; and operation. "No one had proposed a systematic approach to deciding when to apply specific metrics whether at an early stage, throughout the development or at the end," says Purao. Developers should be able to evaluate projects at various stages, rather than having to wait until the project is completed to conduct a test. Knowing which metrics to apply at different stages of software development can lead to fewer problems. For example, a software problem has emerged in the new $16 million computer system of the school district in Baltimore, Md., forcing the school system to pay about $500,000 a month to address the software issue. Purao and Vaishnavi believe their research will help reduce the IT snafus that lead to overruns in cost and delays in the implementation of systems. Click Here to View Full Article

A Fable: The King's Companion
A Fable: Kingdom of Beal
How giant websites design for you
A Fable: Joey's Airplane
A Fable: The Chick's Coat
A Fable: The Table
A Fable: The New Cell Phone
Can Your Customer’s Requirements Be Too Agile?
How to Tell When the Requirements Are Done
Information Audit
Managing Requirements: practical information on managing requirements
Capturing The Value Of Flexibility In Information Technology Project Using Real Option Valuation
Requirement Gathering And Management In Globally Dispersed Teams
Requirements Determination and Requirements Structuring
Requirements Analysis and Specification Briefing Study Guide
The Importance of Requirements Definition in IT Systems Development
Using the System's Security Audit Process and Ethical Hacking to Protect Systems Vulnerabilities in Applications Such As Lotus Notes and SAP
VIDEO: Ultimate Gaming System Requirements

From ACM TechNews, August 5, 2002

"Are Vendors Doing Enough to Improve Software?" Optimize (07/02) P. 15; Parker, Bob; Guttman, William: Bob Parker of AMR Research and William Guttman of Carnegie Mellon University's Sustainable Computing Consortium (SCC) offer differing opinions about whether enterprise software vendors are making enough of an effort to improve the quality of their products. Parker attributes many problems in software quality to external factors, such as over customization of applications, conflicting standards from multiple standards bodies and infrastructure vendors, and project complexity. He also thinks that the perpetual-license model enterprise software markets rely on is flawed, and must be modified with higher initial prices, larger annual fees, and renewable licenses. Guttman, on the other hand, says the fault lies with a software industry that freely admits that its system of rushing new products to market first and delivering patches second is unworkable. "We need to make software as reliable as water and electricity, but we know there's no quick fix," he notes. Guttman asserts that the SCC was formed as a platform where the creation of secure, sustainable, reliable, and high-quality computing can be discussed. Its goals include the development of solid sustainability measurement techniques and tools; the organization of empirical models for studying public policies and how they affect sustainable computing; and the creation of reliability metrics. "The goal is to quantify those best practices and make them more widely available, changing the model from 'release and patch' to 'develop, test, fix, and release,'" Guttman says. Click here to view full article

From ACM TechNews, August 7, 2002

"Why Software Is So Bad," Technology Review (08/02) Vol. 105, No. 6, P. 32; Mann, Charles C.: Engineers posit that software quality is declining because it suffers from a profound lack of design. The increasing size and complexity of programs have significantly reduced the effectiveness of the "code and fix" method, in which programmers write code and use compilers to detect errors, which they then correct. And although component-based programs made up of modular elements are considered to be very useful, critics say their usefulness is canceled by the numerous features wired into software because of marketing pressures. Former Microsoft CTO Nathan Myhrvold adds that constant customer demand for new software and new features is contributing to the reliability shortfall. Software vendors have also turned defective software into a profit center by accompanying it with poorly developed help files that give users no choice but to seek expensive customer support. Some software companies, such as Microsoft, believe they can reverse the decline in quality by dramatically reforming their engineering processes and implementing higher standards of reliability measurement, but there are coders who think that product liability lawsuits will be even more effective in spurring developers to improve their software. "It's either going to be a big product reliability suit, or the government will come in and regulate the industry," forecasts Cigital Labs chief scientist Jeffrey Voas. Critics contend that commercial software developers must stop making quality a secondary priority, which they say is a practice deeply ingrained in corporate culture. http://www.technologyreview.com/featuredstory/401594/why-software-is-so-bad/

The Art And Science Of IT Architecture Design, by J. Dowling

To assure flexibility and lasting value, information system designs and product selection must be guided by an architectural plan for infrastructure and applications systems. The Art of architecture design is in extracting business requirements; the Science is translating them into technology solutions. To read the entire article, click here.

Views of Specifications

Requirements Gathering

Systems Requirements

Evaluating Systems Requirements

Origins of Specifications

Mr. Craft's Presentation
A discussion of CMM and ISO
A Presentation about ISO-CMM
Another Presentation about ISO-CMMI
An overview of ISO-CMM
Another Overview of SEI CMMI

Corporations

From the SEI-CMM Institute

SEI Documents
Published Appraisal Results for CMM Evaluation

CMM Integration

Insights on Program Success

Process Maturity Profile

Other Views on CMM, CMMI and ISO

The Capability Maturity Model and ISO 9000 Standards: Similarities and Differences

The Immaturity of CMM

Capability Maturity Model With Information Systems Development

CMMI and ISO: Success Rate

---

Teams and Team Formation

Launching a Cooperative Learning Team
Bio-inspired tips to create better teams>/a>
Characteristics of Successful Teams
The Guerrilla Guide to Interviewing (version 3.0)
Skills Associated with the SDLC
Importance of Group Members

---

User Expectations

A Fable: Kenny
A Fable: The King's Companion
A Business Perspective of Analysis
The Value of Information Technology (best viewed with Internet Explorer); Power point version
A view of how clients view specifications
10 Business Lessons I Learned from Playing Dungeons & Dragons

From ACM's TechNews, April 19, 2004

"Testing 101: AWOL on the College Campus"
Software Development Times (04/15/04) No. 100, P. 1; Correia, Edward J.

Few college and university computer science curricula include testing for quality, which is a vital ingredient in software development, according to industry experts. Go Pro Management President Robin Goldsmith maintains that college curricula overemphasize people and project management, leaving quality assurance in the lurch: "There's a notion that a project manager should not be directing attention to hands-on skills associated with testing, requirement analysis and design because if they are busy doing that, they are not doing project management," he notes. "Requirements determine what needs to be done, and testing determines if it's being done right." Gartner research director Theresa Lanowitz adds that software quality testing and career goals deserve equal consideration, while both she and Goldsmith agree that the scope of computer science curricula should be expanded to more fully include testing. "Colleges should have parallel tracks on how to put quality code to use by testing against requirements," asserts Lanowitz. A common argument against including software testing in curricula is that testing does not constitute a real career, according to Boston University's Azer Bestavros; Lynn Robert Carter of Carnegie Mellon University's Institute for Software Research International adds that software QA testers usually earn less money and are more likely to have their jobs outsourced. Florida Institute of Computer Science professor James Whittaker strongly believes that companies must place more value in quality if they are to have successful-selling products. He concludes that quality will be the chief point of discernment for applications once those applications and development tools become equal in terms of time-to-market and feature sets. Click Here to View Full Article

From ACM's TechNews, March 31, 2004

"Researchers Question I.T. Subcultural Values"
NewsFactor Network (03/29/04); Martin, Mike

Over three-quarters of IT projects are doomed to failure not because of complexity, usability, and new technology's unpredictability, as many people assume, but because an IT occupational subculture often clashes with users and managers, according to Jeffrey Stanton of Syracuse University. "Occupational subcultures are groups of individuals who, based upon their occupation, develop their own language, values and behaviors that distinguish them from other groups within an organization," Stanton observes. His conclusion that subcultural conflicts were responsible for failed IT projects is based on 18 months of research with Kathryn Stam encompassing 12 New York organizations that were implementing major tech projects, and over 100 interviews. The technical jargon IT staffers use acts as a barrier that blocks outsiders' access to knowledge, while another source of frustration is IT personnel's tendency to explain things too rapidly. "A tech problem often seems routine to the IT worker, but--as one user said--it doesn't help 'when they come in and go zoom, zoom, zoom, zip, zip, zip with a mouse and they've totally lost me, so I never learn anything,'" notes Stanton. IT workers, on the other hand, often harbor feelings that their contributions are under appreciated by management and end users. Clif Boutelle of the Society for Industrial and Organizational Psychology attests that outsiders respect IT workers who are helpful, responsive to problems, and are "good teachers," although Stam reports that many IT personnel she and Stanton interviewed expressed a reluctance to nursemaid non-IT personnel. Stanton says his research emphasizes the need for organizations to close subcultural gaps, but cautions that assigning blame is more likely to exacerbate the situation. A more effective solution is acknowledging and understanding subcultures within an organization.

---

Visio

Visio Demos

Microsoft Overview

Demo from Microsoft

Visio Self Training

Linking Data to Diagrams

How To Use MS Visio

Visio: Using the Status Bar

Using Autoconnect

Applying a Theme

Connect your Data to the Diagram

Add and Customize Data Graphics

Applying a Theme

Visio Demos

Measures of the value of information
alternate syllabus (an example of data, not information)
Information Comparison
Building Blocks of IS
Information Flow

Systems Thinking from Wikipedia
Trials and Tribulations of a Business Systems Analyst
What Does A Systems Analyst Really Do?
What is Systems Analysis
Systems Development Life Cycle
Process v. Data Orientation
Different Types of Systems
Stage Deliverables
Deliverables
More about Deliverables
Six 'Soft Skills' Every Analyst Needs to Know
Agile Methods
Soft Systems Methods
Benefits of Systems Analysis
unintended consequences in systems analysis
What are the benefits of modern systems analysis? Find out here.
Systems Analysis Want Ads
Systems Development Life Cycle
Overview of the Products of the SDLC phases
Systems Analysis Deliverables
Process-Oriented vs. Data-Oriented Analysis
Different Types of Systems
Stage Deliverables
Deliverables
More about Deliverables
Agile Methods

A Systemic Perspective from the Systemic Perspective Series.

Evolution of Systems Thinking

Systemic Perspective

Habits of a Systems Thinker

Systems Thinking

System Boundaries

System Perspective Intent

Health Care as an Example