Software Engineering and CS Resources !

Provide useful guidelines, tips, and references for Computer Science and Software Engineering students, professional, and normal computer users that we have found from our research so that you don't have to spend 100's of hours researching or searching those information again.

Location: WI

Sunday, October 15, 2006

Software Lifeccle

A life cycle is the sequence in which a project specifies, prototypes, designs, implements, tests, and maintains a piece of software. Explicit recognition of a life cycle encourages development teams to address development issues at the appropriate time; for example, to establish basic software requirements before design or coding begins. We recommend that developers roughly follow the staged delivery model (below) when designing significantly new versions of the full model and when developing large components and libraries.

Four fundamental process activities

Software specification (requirements - functionality & constraints)
Software development (design, implementation)
Software validation (ensure that the software meets the customer needs)
Software evolution (evolve to meet changing customer needs)

Ordering of software processes and activities.
Waterfall model: a linear sequence of activities; after each stage is defined it is 'signed-off' and development goes on to the next stage

requirements definition
system and software design
implementation & unit testing
integration & system testing
operation & maintenance (including installation & checkout)

Evolutionary development: planned development of multiple releases of a product (as it evolves). Initial system is developed from very abstract specifications and the systems is refined with customer input. Specification, development and validation are interleaved.

Formal transformation: A formal mathematical specification is transformed, using mathematical methods, to a program.
System assembly from reusable components: The development process focuses on integrating parts.

Incremental model: concept, requirements, (design, implementation, test, installation & checkout, operation & maintenance, replacement)*.
Boehm's spiral model: a sequence of cycles each of which is the sequence
Elaboration of entity objectives, constraints, and alternatives
Evaluate alternatives relative to objectives and constraints, and identify major sources of risk.
Elaborate the definition of software entities for a project.
Plan the next cycle. Terminate for a project if it is too risky. Secure managment commitment.
Embedded system model (DoD-Std-2167 (1988))
Sawtooth Model
Shark Tooth Model
Unified Software Development Process
Issue-Based Life Cycle Model
Synchronize and stabilize model (Microsoft): what team members are doing is continuously synchronized.
Planning phase
vision statement
specification document
schedule and feature team formation
Design phase
1. first 1/3 of features (critical features, shared components)
2. second 1/3 of features
3. final 1/3 of features (less critical features)
Stabilization phase
internal testing
external testing
release preparation
Cleanroom process model
Extreme Programming
Iterations to First Release
Maintenance - the normal state of an XP project which consists of repeated cycles of the previous steps.

Wednesday, September 27, 2006

The Mythical Man-Month

Essays on Software Engineering / Frederick P. Brooks, Jr

Adding people to a late project makes it later
If a certain job can be done by ten people in one month, they say that this job requires ten man-months (or “person-months” as they are called today). Simple arithmetic shows that if you allocate twenty people to that same job, if should be finished in half that time. I guess this kind of logic must be right in some sort of projects, because otherwise, economists wouldn't have been so fond of it.In the world of software design, however, this premise is an outright fallacy. There is no gentler way to put it. A program that can be crafted by one programmer in two months will probably take two programmers three months to complete.

As far back as 1975, when software engineering was a very young profession, Frederick Brooks keenly observed that the man-month concept is but a myth.The problem with software project management back in the 70's was that most managers were educated in the fields of economics rather than computing, and many of the theories they were familiar with were simply not applicable to software projects. In fact, there were no equivalent theories for software design projects. And since even today, most software projects are never released on schedule, we have a bold indication that this problem, along with many other problems that Brooks outlines in his book, is still unsolved.In the preface to the 20th Anniversary Edition, Brooks writes:

To my surprise and delight, The Mythical Man-Month continues to be popular after 20 years.Actually, this is really a shame. It indicates that in twenty years, the software industry hasn't learned some serious lessons, and it is still paying the price. Software engineering is still considered to be more of a strange art than an engineering profession. Truly, I would be the first to admit that there is art in software writing. It is a beautiful, delicate art that can be appreciated only by others versed in the same art. It is, I believe, a more fascinating art than architecture, more arresting than painting, more thought-provoking than music, when done by a true coding artist. However, an architect will not let the artistic aspect of designing of a house distract him from assuring that the house will withstand at least minor earthquakes.

This realization is yet to dawn on most software professionals, those who consider themselves artists only and refuse to refer to themselves as engineers (an interesting solution was suggested by a good friend of mine, who considers himself a “software architect.”)Brooks' work is simply a must to anyone who considers a profession in the software business, and doubly-so for would-be managers in this field.

The book not only outlines the problems, but also suggests some interesting solutions (“The Surgical Team,” for example). It outlines some very important pitfalls (like the “Second System” effect) that every professional in the field should be aware of. And finally, it provides many important insights and case studies.Most of the material in the book is as relevant today as it was when originally written. Understandably, though, part of the material is outdated. In the 20th Anniversary Edition, rather than update the original text, which is considered “classical,” Brooks has wisely decided to add update chapters. These discuss the issues presented while shedding fresh light from the 90s on them.

Personally, I recommend reading the relevant parts of Chapter 18 after reading each previous chapter. Chapter 18 is titled, “Propositions of The Mythical Man-Month: True or False?”, and it contains updated information about each of the chapters from 1 to 17.Finally, this new edition includes a reprint of Brooks' famous essay, “No Silver Bullet”, which was originally an invited paper for the IFIP '86 conference in Dublin, and later published in Computer magazine. In this paper, Brooks speculated that no technology will be found, within ten years of its publication (in 1986), which will enhance the process of software development by an order of magnitude. Nine years later, in retrospect, Brooks sadly notes that he was right.

  • Ref: Frederick P. Brooks, Jr, "The Mythical Man-Month"

Friday, September 08, 2006

Software Errors Cost U.S. Economy $59.5 Billion Annually

NIST Assesses Technical Needs of Industry to Improve Software-Testing

Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a newly released study commissioned by the Department of Commerce's National Institute of Standards and Technology (NIST). At the national level, over half of the costs are borne by software users and the remainder by software developers/vendors.The study also found that, although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects. These are the savings associated with finding an increased percentage (but not 100 percent) of errors closer to the development stages in which they are introduced. Currently, over half of all errors are not found until "downstream" in the development process or during post-sale software use.

NIST funded the study, which was conducted by the Research Triangle Institute (RTI) in North Carolina, as part of a joint planning process with industry to help identify and assess technical needs that would improve software-testing capabilities. Findings of the 309-page report are intended to identify the infrastructure needs that NIST can meet through its research programs.

"The impact of software errors is enormous because virtually every business in the United States now depends on software for the development, production, distribution, and after-sales support of products and services," said NIST Director Arden Bement. "Innovations in fields ranging from robotic manufacturing to nanotechnology and human genetics research have been enabled by low-cost computational and control capabilities supplied by computers and software."

In 2000, total sales of software reached approximately $180 billion, supported by a large workforce encompassing 697,000 software engineers and 585,000 computer programmers.
Software is error-ridden in part because of its growing complexity. The size of software products is no longer measured in thousands of lines of code, but in millions. Software developers already spend approximately 80 percent of development costs on identifying and correcting defects, and yet few products of any type other than software are shipped with such high levels of errors. Other factors contributing to quality problems include marketing strategies, limited liability by software vendors, and decreasing returns on testing and debugging, according to the study. At the core of these issues is difficulty in defining and measuring software quality.

The increasing complexity of software, along with a decreasing average product life expectancy, has increased the economic costs of errors. The catastrophic impacts of some failures are well-known. For example, a software failure interrupted the New York Mercantile Exchange and telephone service to several East Coast cities in February 1998. But high-profile incidents are only the tip of a pervasive pattern that software developers and users agree is causing substantial economic losses.

Study Design and Background Facts
In the study, RTI identified a set of quality attributes and used them to construct metrics for estimating the cost of an inadequate testing infrastructure. Two in-depth case studies were conducted, one in the manufacturing sector (transportation equipment) and one in the service sector (financial services).

For the analysis of transportation equipment industries, data were collected from 10 vendors of computer-aided design/manufacturing/engineering (CAD/CAM/CAE) and product data management (PDM) software, and from 179 users, primarily automotive and aerospace companies. Approximately 60 percent of the automotive and aerospace manufacturers surveyed reported significant software errors in the previous year. Respondents who experienced errors reported an average of 40 major and 70 minor software bugs per year in their CAD/CAM/CAE or PDM software systems.

The total cost impact on these manufacturing sectors from an inadequate software-testing infrastructure is estimated to be $1.8 billion, and the potential cost reduction from feasible infrastructure improvements is $0.6 billion. Users of CAD/CAM/CAE and PDM software absorb approximately three-fourths of the total impact, with the automotive industry representing about 65 percent and the aerospace industry representing 10 percent. Software developers experience the remaining one-fourth of the costs.

For the analysis of financial services, data were collected from four developers of financial electronic data interchange (FEDI) and clearinghouse software as well as the software embedded in routers and switches that support electronic data exchange, and from 98 software users, primarily banks and credit unions. Approximately two-thirds of the software users surveyed reported experiencing major software errors in the previous year. Respondents that did have major errors reported an average of 40 major and 49 minor software bugs per year in their FEDI or clearinghouse software systems. Approximately 16 percent of those bugs were attributed to router and switch problems, and 48 percent were attributed to transaction software problems. The source of the remaining 36 percent of errors was unknown. Typical problems encountered due to bugs were increased person-hours used to correct posting errors, temporary shut down leading to lost transactions, and delay of transaction processing.

The total cost impact on the financial services sector from an inadequate software-testing infrastructure is estimated to be $3.3 billion. Potential cost reduction from feasible infrastructure improvements is $1.5 billion. Software developers absorb about 75 percent of the economic impacts. Users experience the remaining 25 percent of costs, with banks accounting for the majority of user costs.

The annual cost to these two major industry groups from inadequate software infrastructure is estimated to be $5.18 billion. Based on similarities across industries with respect to software development and use and, in particular, software-testing labor costs, RTI projected the cost to the entire U.S. economy. Using the per-employee impacts for the two case studies, an extrapolation to other manufacturing and service industries yields an approximate estimate of $59.5 billion as the annual cost to the nation of inadequate software testing infrastructure.

Thus, if all software bugs could be identified and removed instantly (in real time), the combined economic benefits to the two industry groups and to the economy would be $5.85 billion and $59.5 billion, respectively. Realizing that such a "perfect infrastructure" is not attainable, industry experts were asked for estimates of a plausible reduction in delayed identification and removal of software errors. Based on this information, a "feasible improved infrastructure" scenario was constructed. For this scenario, software developers were asked to estimate the potential cost savings associated with enhanced testing tools, and users were asked to estimate cost savings if the software they purchase had 50 percent fewer bugs and errors. This improved infrastructure scenario is estimated to result in a combined annual benefit of $2.10 billion to the two industry groups studied, and $22.2 billion to the U.S. economy.

Thursday, August 31, 2006

Principles behind the Agile Manifesto

We follow these principles:
  • Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
    Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly


Computer Science & Software Engineering Code of Ethics

Software engineers shall commit themselves to making the analysis, specification, design, development, testing, and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety, and welfare of the public, software engineers shall adhere to the following Principles:
  • Public: Software engineers shall act consistently with the public interest.
  • Client and Employer: Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
  • Product: Software engineers shall ensure their products and related modifications meet the highest professional standards possible.
  • Judgment: Software engineers shall maintain integrity and independence in their professional judgment.
  • Management: Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
  • Profession: Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
  • Colleagues: Software engineers shall be fair to and supportive of their colleagues.
  • Self: Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

    The Code instructs practitioners about the standards that society expects them to meet, and what their peers strive for and expect of each other.

    Ref: Communications of the ACM, Volume 42, Number 10 (1999), Pages 102-108