From ACM TechNews, November 17, 2003.

From ACM's TechNews,

From ACM's TechNews, January 23, 2006.

"'Play' Model of Information System Design Makes Teammates of Users and Designers"
Penn State Live (01/11/06)

System designers are focusing too much on the "killer application," and neglecting the different needs of users, according to researchers at Penn State. At the 26th International Conference on Information Systems in Las Vegas, Frederico Fonseca, assistant professor in the School of Information Sciences and Technology (IST), and James Martin, a professor emeritus of the Penn State psychology department, presented their argument for having designers and users act as teammates during the development process. In their paper, "Play as the Way Out of the Newspeak-Tower of Babel Dilemma in Data Modeling," they suggest that a back-and-forth dialogue between designers and users will ultimately allow for the development of IT systems that meet the various needs of its users. "For example, departments in banks interpret the term 'loan date' differently," says Fonseca. "One department views it as the date when the loan was applied for, another when the loan was approved and yet another when the money was released." They refer to communication of designers and users as 'play,' enterprise-wide solutions as 'newspeak,' and multiple systems as the 'Tower of Babel problem.' Fonseca and Martin say the failure to design systems that address the perspective of every user is the problem, and not the user. Click Here to View Full Article

From ACM's TechNews, January 9, 2006.

"Skills That Will Matter"
InformationWeek (01/02/06) No. 1070, P. 53; McGee, Marianne Kolbasuk

A new report from the Society for Information Management is another indication of how important business and industry knowledge, and communications and negotiating skills, have become for IT workers. Of the 100 IT managers who identified the most important talents to keep in-house through 2008, more than 77 percent of respondents cited project planning, budgeting, and scheduling; followed by 75 percent who listed functional-area process knowledge; and 71 percent who noted company-specific knowledge. Three technical skills topped 60 percent in systems analysis at 70 percent, systems design at 67 percent, and IT architecture and standards at 61 percent. And 55 percent of IT execs mentioned security skills. "The higher you go in the IT organization, the more you need to know about business," says Stephen Pickett, new SIM president and CIO of transportation company Penske, as firms rely more on off-the-shelf software and outsource IT. Pickett describes IT as an umbrella that allows someone with IT skills to see more of a company. More employers are starting to demand business-technology professionals who have "customer-facing, client-facing" skills and understanding, the survey also reveals. Click Here to View Full Article

The Astronomer
The Bee and the Beetle
Cafe
Buying a Car
The Chevrotain
The Chick's Coat
The Curse
The Contest
Dancing Monkeys
The Elves' Mistake
A Foolish Man Buys Shoes
The Fox and the Grapes
The Frog
The General's Horse
George's Flight -- or Plight
Great Warrior
Happy Fish
The Houses
Trying To Get Home
Joey's Airplane
Kingdom of Beal
The King's Companion
The King and the Castle
Mr. Kringle's Ornaments
Let's Talk Over Lunch
The Lion's Party
Look Before You Leap
The Medicine Man
Mother Hen
The Mouse and the Crow
The Ph.D. and the Donkey
A Suitable Partner
The Rabbit and the Turtle
The Seven Little Lambs
Seven Sons
The Shoemaking Machine
Six Blind Men and the Elephant
The Old Man Who Wanted to Quit Smoking
Take Me Out To the Ballpark
The Tale of Many Zebras
The Timbla
The Travelers
The Warrior and the Island
The Water Fountains
The Water Shortage
Weeville
Whale Tales
What's in a Name?
The Wrong Direction

Agile Methodology and System Analysis
The Alignment of Business and IT: Integrating Opposing Forces
Analysis and Enterprise Resource Planning
Automated Tools
Breaking the Rules: A Closer Look into the Business Rules Management Systems
Capability Maturity Model With Information Systems Development
Capturing The Value Of Flexibility In Information Technology Project Using Real Option Valuation
Comparison of Methodologies
Comparison of Diagramming Tools
Comparison of Project Management Software
Conflict Resolution in Project Management
Data Modeling In Information System Analysis
Decision Making in Information Technology Acquisition: A System Analysis Approach
Defining User Requirements During the Analysis Phase: A Look at Use Cases
e-CRM
Enterprise Resource Planning: Factors Affecting Success and Failure
Extreme Programming
The Importance of Requirements Definition in IT Systems Development
Incorporation Of Joint Application Design (JAD) In Systems Requirement Determination
Intranet Usability
IT Enterprise Architecture
Joint Applications Design
Joint Application Development (JAD)
A Laboratory Example
Managing User Expectations
Negotiating Contracts
Object-Oriented Analysis
Object Oriented Analysis and Design: What is it? How Does it Work? Why is it used?
Object-Oriented Analysis Methodology
A Primer to Communicating as a Systems Analyst in Today’s World
Project Management in Enterprise Resource Planning (ERP) Implementation
Project Success And Failure...
Requirements Determination and Requirements Structuring
Requirement Gathering And Management In Globally Dispersed Teams
Requirement Analysis for Portfolio of IT Decisions in A/E Firms
Risk Identification in IS projects – the sooner the better
Scope Creep
Selecting Information Technology Projects
Soft Systems Methodology (SSM) in Information System Analysis
Success Factors in Higher Education Administrative Systems Implementation...
The Effective Methodology for System Requirement Analysis
Understanding The Aspects Of The Customer And Resolving Differences...
Usability Testing
Virtual Project Management
Web Applications: Vulnerabilities and Security
Web-based Information Systems
Writing Effective Use Cases

Brainstorming Pitfalls and Best Practices from ACM's Interactions, September-October, 2006.
An example of IDE-O's Work
Read more about creativity from the New York Times

From Ian I. Mitroff and Harold A. Linstone, The Unbounded Mind: Breaking the Chains of Traditional Business Thinking, New York: Oxford University Press, 1993.

Almost without exception, all who write about the new, global information age acknowledge that we are literally drowning in an overload and overabundance of information. Never before has humankind had access to so much, so quickly, and from every part of the globe. We have more data and information on every conceivable subject, yet less understanding at the same time. Data and information do not automatically lead to greater insight; they may now travel at the speed of light, but understanding and wisdom do not.

There is also common agreement that "data," "information," and "knowledge" are not the same, even though they are often -- wrongly so -- used interchangeably. Their differences are often as unclear to the experts as to the layperson.

One aspect above all else is especially disturbing. It is the strong, taken-for-granted assumption that agreement between the monumental and voluminous databases that both government and businesses are constantly producing will eventually result, and further that agreement itself is fundamentally desirable. -- p.20

In the end, the most general conclusion is "seek agreement or consensus but do not trust them fully." Agreement and consensus are important in reaching conclusions and in achieving the necessary support to carry out complex, important policies. However, as with all things human, they cannot be followed blindly. Nor are they the ultimate consideration for deciding all important questions. -- p. 37

Finally, we can state some rules of thumb ....

      ·Seek the obvious, but do everything in your power to challenge and even ridicule it.

      ·Question all constraints. The most limiting constraints in building a model or a representation of a problem are usually imposed not by the problem itself but by the mindset of the problem solver.

      ·Challenge as many assumptions about the problem and the model as possible. Remember that what seems self-evident to the problem formulator is not always evident to others.

      ·Question the scope or the definition of a problem or model. Frequently what is omitted from the statement of a problem or model is more important than what is included.

      ·Question whether a problem is to be "solved," "resolved," or "dissolved." There are important differences between "solving," "resolving," or "dissolving" a problem. They are not necessarily the same. To "solve" a problem means to produce an exact or optimal solution to it. To "resolve" a problem means to seek a solution that is "good enough." On the other hand, to "dissolve a problem is to realize that there may be some other problem that is more important to focus one's attention on. The old or initial problem may still exist but may not be as important in the broader scope of things.

      ·Finally question the logic itself. Being logical and being right are not always the same. The more logical a solution to a complex problem sounds, the more strongly it deserves to be challenged. -- p. 47-48

The Alignment of Business and IT: Integrating Opposing Forces
Breaking the Rules: A Closer Look into the Business Rules Management Systems
Decision Making in Information Technology Acquisition: A System Analysis Approach
Places to Intervene in a System
Risk Identification in IS projects – the sooner the better
The Importance of Requirements Definition in IT Systems Development
e-CRM
To learn more about interacting with clients, read the article Know Thy Client
You can lower the odds of being outsourced Peter Coffee's Dirty Dozen IT Embarrassments

A Primer to Communicating as a Systems Analyst in Today’s World
To learn more about interacting with clients, read the article Know Thy Client

Comparison of Diagramming Tools

Process Modeling
Introduction to Data Flow Diagram (DFD)
Data Flow Diagram (DFD) Example (Context and Level 0 Diagrams)
Data Flow Diagram (DFD) Example (Level 4 Explosion)
A course at University of Baltimore

Introduction to Entity Relationship Diagrams
An example of Entity Relationship Diagrams
Entities and Attributes
ER Primer
ER Discussion
The Process of Drawing E-R Diagrams
Entity-Relationship Diagrams
Guidelines
Domain Analysis
ERDIAG
Data Modeling In Information System Analysis

Overview
Use Case Notation
An Example

Data Dictionary Example
More samples

Automated Tools
CASE Tools and the Productivity Paradox
A Comparison of Diagramming Tools
CASE Tools
The Metaview Project (CASE generation)
Arcadia Research Project (tools and techniques for software engineering)

Specific Products

ADOit

Artiso Visual Case

DB-Main

IEF/Cool-Gen

      The duick.com COOL:Gen Index

       IEF Instructions

       An example of use of IEF-Composer is available for an ordering system

iGraphx Flowcharter

MetaCase/MetaEdit+

Microsoft Visio

Omnigraffle

Open Source CASE Tools

Rational Rose

SmartDraw

SmartDraw ERD

Tigris: Open Source Software Engineering Tools

Visible Analyst

A Fable: The Bee and the Beetle
ERP and analysis
IT Enterprise Architecture
Analysis and Enterprise Resource Planning
Software That Can Make a Grown Company Cry
Enterprise Resource Planning: Factors Affecting Success and Failure
Success Factors in Higher Education Administrative Systems Implementation: A Review of the Literature
More SAP References
Project Management in Enterprise Resource Planning (ERP) Implementation

Estimation
Evaluating Information Technology Investments
An Analytical Framework for Capital Planning and Investment Control for Information Technology
Estimation Process

Function Points and Metrics

Function Point Explanation

Metrics Sites

Estimating and Metrics

Longstreet Consulting -- Function Point Consulting

Software Economics

Benefits of Function Point Counting

Productivity of Software Since 1970

Function Point Articles

Online Training Video regarding Function Points

Function Point Manual

Ethics Survey
ACM Code of Ethics and Professional Conduct

From Knowledge@Emory, August 14-28, 2002

What's Behind the Breakdown in Ethics? The vast majority of Fortune 500 companies have codes of ethics, yet the spectacle of top executives being led away in handcuffs or shrinking under the bright lights of a Congressional hearing is becoming all too familiar. What's behind the lack of ethics in business today? Ethics professors and other Emory scholars explore the reasons for the current crisis. Read article.

Estimation and Feasibility Analyses
Initiating Projects
Project Risks
Project Mix
To learn more about interacting with clients, read the article Know Thy Client
Political Considerations in Requirements Analysis
Managing Customer Expectations
Screening Feasibility Issues
Overview of Issues

Worth reading

Guides & How to Manuals

Especially: A Program Manager's Guide to Buying Performance, which includes:

     System Operational Effectiveness

     Acquisition Focus

From ACM TechNews, August 14, 2002

"Why Tech Falls Short of Expectations, " Optimize (07/02) No. 9, P. 20; Hartman, Amir: Prodded by Y2K concerns, the Internet boom, and an unstable economy, many companies have made excessive IT investments that have not generated sufficient returns or fulfilled corporate goals. Mainstay Partners conducted a four-year survey of 450 companies across a variety of industries, and discovered that IT-smart businesses that have achieved significant returns on investment (ROI) share three core IT strategies: Optimization of existing processes for incremental gains; the reengineering of core processes to handle efficiency and productivity fluctuations; and the creation of new processes and capacity for growth. The study also revealed many instances of bad IT investment management, including underestimation of spending, lack of a decision-making process and senior executive involvement, poorly defined business metrics, inadequate alignment of IT investments to corporate strategy, poor communication of IT strategy, and suboptimization due to poor governance. Mainstay outlines a number of business principles that companies could follow to better manage their IT investments. One principle is to forge a solid link between IT and business strategy by building a good business case for every major IT program, funneling IT funding directly from the business units' operating budgets, holding executives accountable for IT investments, and annually conducting "voice of the customer" evaluations. Other principles include promoting simple and flexible technology via a road map that balances the need for ease-of-use and next-generation capabilities; making IT a strategic adviser to the enterprise by IT-business collocation; optimizing IT's asset value by implementing value-based availability, holding quarterly operational reviews, not overcommitting to initiatives, and deploying strict metrics, among other things; and delivering near-term results every three months. http://www.optimizemag.com/issue/009/roi.htm

The Dilbert Zone
Gene Fool by Scott Adams, and 20th Century Technology
Random (Humorous) Thoughts on Information Systems Analysis

Life Cycle Information
Overview of Methodologies
Methodologies: Best Practices from the Standish Group
Joint Applications Design
Comparison of Methodologies
Methodologies.com
Selected Methodologies on the Web
Incorporation Of Joint Application Design (JAD) In Systems Requirement Determination
Joint Application Development (JAD)
Systems Development Methodology Books
Modern RAD
IT Methodologies on the Web
Soft Systems Methodology (SSM) in Information System Analysis
Requirements Analysis and Specification Briefing Study Guide
From ACM TechNews, December 5, 2003.

From Good Experience newsletter, November 17, 2003.

The ROSE Framework

The ROSE framework is a distillation of some of the more valuable lessons I've learned in customer experience work over the past 10 years or so.

I have presented ROSE at various events and organizations recently and people have said they found this useful - so here are some of the high points.

ROSE is Results, Organization, Strategy, Experience.

(I call it ROSE because it's more positive than SORE, and less racy than EROS. Never promise a speech on EROS and then talk about customer experience strategy the whole time.)

RESULTS

Customer experience work only matters to a business if it generates *business results*. That's different from *usability results*, which means improving "task success" or "time on task."

Business results are metrics that the CEO can understand: revenue, conversion rate, operating savings. You have to create a team and a process to measure those results; the metrics-announcement e-mail won't magically float into your inbox.

Most importantly, you have to use the right method to create those improvements in the first place. This is different from writing a "usability report" that no one reads; I mean actually changing what the user reads, clicks, touches. And the only way you'll create any tangible change is with the next bullet.

ORGANIZATION

The only way changes ever get made to a customer experience is if the organization buys into those changes.

And the only way the decision-makers buy into those changes is if they feel some ownership.

Hint: no one feels ownership when a usability researcher plops a report on the desk and makes academic pronouncements about the site.

Involve the decision-makers in your process - the listening labs, the strategy sessions, the wireframes - and they might just buy in.

By the way, I've written about this in the past:
  ·http://www.goodexperience.com/columns/03/0808.disappear.html
  ·http://www.goodexperience.com/columns/03/0620.org.html

STRATEGY

Fry the biggest fish you can. This means, try to solve the most important problems in the user experience. These are almost always strategic, not tactical.

For years, usability professionals have concerned themselves with tactical details in the user experience (where to put the navbar, exactly how many items it should hold, etc.) and have missed the reality of customer experience: it's *strategic*.

Here's a common example: If the user can't figure out what the site does, or what its primary feature is, don't do *anything* else on the site until you fulfill the user's key unmet need. Don't rewrite the site map, don't run tactical usability tests, and for heaven's sake, don't spout off about "branding" and run a new multi-million-dollar ad campaign. (Yes, I've seen it happen.)

Instead, fix the strategic problem. Make the experience better. (See next bullet.)

EXPERIENCE

Remember that this entire process is about the *experience* that a user has on the site, or in the store, or with the product.

It's not primarily about "branding" or "market penetration" or "information architecture" or even "usability." Those things may be important, but the *primary* concern is, did the user have a good experience?

It's a holistic question that joins many parts of the organization, has strategic implications, and can generate huge results. But you have to ask the right question: is it a good experience?

Agile Methods
Challenges of Migrating to Agile Methodologies

From ACM's Tech News, March 15, 2006.

Agile Programming Has Fallen Short, Conference Told
InfoWorld (03/13/06) Krill, Paul

In a presentation at the SD West 2006 Conference, Construx Software Builders' Steve McConnell argued that agile software development has not yet lived up to its promise, having been focused more on processes and tools than on people and interactions. "It seems to me that the promise of agile development has fallen short at least so far," said McConnell. In his presentation, McConnell offered his lists of best and worst ideas. McConnell claimed that agile development has been framed on the belief that developers can anticipate every possible requirement before building an architecture, an idea that made his "worst" list. Among McConnell's list of best ideas are the imperative of incremental software development, that fixing glitches decreases costs, and that software estimation abilities can be improved over time. McConnell also lauded the notion that full reuse is the most powerful form of reuse, and that intellectual flow guides software projects. Making McConnell's worst list are the ideas that the only software models are fully iterated or completely non-iterated, defect cost increase dynamics do not affect agile development projects, and that there is such a thing as a one-size-fits-all development approach. Click Here to View Full Article

From ACM TechNews, July 22, 2002 "Taking Programming to the Extreme," Technology Review Online (07/19/02); Sherman, Erik: So that they can churn out quality software in a market clamoring for fast rollouts of new products and features, software companies are increasingly adopting development tactics that emphasize collaborative engineering. "Agile development" emphasizes teamwork, flexibility, and end-user cooperation. One form of agile development is extreme programming, in which two programmers work together--one writes the software code while the other checks for mistakes and finds possibilities for improvement; continuous testing is also a key element of the process. Peer programming involves development partners taking turns writing code and describing logic functions, and supports constant review by regularly switching partners. Testing is also undergoing a change: For example, pharmaceutical software developer Phase Forward has instituted a strategy in which programmers and quality assurance personnel continuously interact to find and fix bugs during application development; the traditional testing approach involves programming, followed by separate quality testing. Customer feedback is another form of quality control, one that Cognizant Technology Solutions follows. Rather than setting formal specifications followed by code writing, Cognizant project starts with prototypes that are adjusted by an "industrialization" cycle, in which future users make suggestions during the development process. However, consumers themselves may set the limits of software quality by determining what is acceptable.

http://www.technologyreview.com/articles/wo_sherman071902.asp

Compatible partners in agile programming
Agile Methodology and System Analysis
Extreme Programming
See also Object-Oriented Methodologies

DSM Forum
Rational Methodology
OOATutorial
OOA Bibliography
OSA: Object-oriented Systems Analysis
MOOSE: Method for Object-Oriented Software
Writing Effective Use Cases

Overview of Project Management by Obernuefemann and Lemmons.
Overview of Project Management by Piesbergen
Project Management Issues

Fables

A Fable: The Shoemaking Machine

A Fable: The General's Horse

Threats to Project Management

Comparison of Project Management Software

Conflict Resolution in Project Management

IT Metrics for Success

Project Management for Mission Critical Systems

Project Success And Failure: What Is Success, What Is Failure, And How Can You Improve Your Odds For Success?

Risk Management

Scope Creep

Virtual Project Management

Introduction of Prototyping
An analogy: Prototyping Star Wars Figures as an example of how different kinds of prototypes are used to answer different kinds of questions
Design Prototyping Technologies (DPT)
The Effects of Practical Business Constraints on User Interface Design
Variations in interpretation of specifications (requires Powerpoint: you must "run show" and turn on speakers to appreciate)

Fables

A Fable: Joey's Airplane

A Fable: The Chick's Coat

Examples

An example of how prototyping can be used to elicit user feedback: this example is replicated here for you to consider as a way of doing prototyping, and does not function

The Analysis and Prototyping of Effective Graphical User Interfaces

Prototyping Tools

Card Sorting

Web Page Test

Paper Prototyping

The Paper Prototyping Website

Paper Prototyping

What is Paper Prototyping?

Paper Prototyping: Getting User Data Before You Code

How do we decide if we should use paper?

Five Paper Prototyping Tips

Checklist: Working Interface or Paper Prototype

Paper Prototyping Methods

Six Signs that you Should Use Paper Prototyping

Pros and Cons of Paper Prototyping

Using Paper Prototypes to Manage Risk

Examples

More References

Introduction to Interviews
Interview Hints
How to Improve It? Ask Those Who Use It
Interview Content
The Cognitive Interview
Guidelines for determining Specifications

Fables

A Fable: The King's Companion

A Fable: Kingdom of Beal

Missing the point

    Example 1

    Example 2

    Example 3

Interviewing Tools

Card Sorting

Web Page Test

Testing
Software QA Articles - Articles on important software QA topics.
Search for Zero Defect Software
The Book of Testing
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. Click Here to View Full Article

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. Click Here to View Full Article

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. http://www.bayarea.com/mld/cctimes/business/6938306.htm

"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. http://www.sdtimes.com/news/087/special1.htm

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
A Fable: Joey's Airplane
A Fable: The Chick's Coat
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

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 overcustomization 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. http://www.optimizemag.com/issue/009/squareoff.htm

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/articles/mann0702.asp

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

A discussion of CMM and ISO
A Presentation about ISO-CMM
An overview of ISO-CMM

Corporations

Published Appraisal Results for CMM Evaluation

Companies certified under ISO.

From the SEI-CMM Institute

SEI Documents

Capability Maturity Models

CMM Integration

CMM Publications

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

Launching a Cooperative Learning Team
Characteristics of Successful Teams
The Guerrilla Guide to Interviewing (version 3.0)
Skills Associated with the SDLC
Winning Project Teams
Key To Successful Software Development: Teamwork, Not High Tech, Study Shows
Importance of Group Members

The King's Companion
A Business Perspective of Analysis
The Value of Information Technology (best viewed with Internet Explorer); Powerpoint version

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 underappreciated 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. Click Here to View Full Article

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?
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
Systems Development for Different IS Types
Systems Theory
What is a System?
IT Interaction Model: nice description of the components of a system.
Systems Development Methodology
Principia Cybernetica: What is Systems Analysis?
The Philosophy of Systems Analysis: Extreme Programming (XP)
To Combat Terrorism, a Systems Approach is Vital --- read the article
Systems Analysis: A Tool to Understand and Predict Terrorist Activities
Systems failure begins with poor systems analysis. Read about the Denver Airport.
This is an actual e-mail that I received, which I provide to you because it provides some good insights.