Decision support system

Decision support systems constitute a class of computer-based information systems including knowledge-based systems that support decision-making activities.

Definition

Decision Support Systems (DSS) are a specific class of computerized information system that supports business and organizational decision-making activities. A properly-designed DSS is an interactive software-based system intended to help decision makers compile useful information from raw data, documents, personal knowledge, and/or business models to identify and solve problems and make decisions.

Typical information that a decision support application might gather and present would be:

• an inventory of all of your current information assets (including legacy and relational data sources, cubes, data warehouses, and data marts),
• comparative sales figures between one week and the next,
• projected revenue figures based on new product sales assumptions;
• the consequences of different decision alternatives, given past experience in a context that is described.

As with the definition, there is no universally-accepted taxonomy of DSS either. Different authors propose different classifications. Using the relationship with the user as the criterion, Haettenschwiler differentiates passive, active, and cooperative DSS. A passive DSS is a system that aids the process of decision making, but that cannot bring out explicit decision suggestions or solutions. An active DSS can bring out such decision suggestions or solutions. A cooperative DSS allows the decision maker (or its advisor) to modify, complete, or refine the decision suggestions provided by the system, before sending them back to the system for validation. The system again improves, completes, and refines the suggestions of the decision maker and sends them back to her for validation. The whole process then starts again, until a consolidated solution is generated. Using the mode of assistance as the criterion, Power differentiates communication-driven DSS, data-driven DSS, document-driven DSS, knowledge-driven DSS, and model-driven DSS.

• A model-driven DSS emphasizes access to and manipulation of a statistical, financial, optimization, or simulation model. Model-driven DSS use data and parameters provided by users to assist decision makers in analyzing a situation; they are not necessarily data-intensive. Dicodess is an example of an open source model-driven DSS generator .
• A communication-driven DSS supports more than one person working on a shared task; examples include integrated tools like Microsoft's NetMeeting or Groove
• A data-driven DSS or data-oriented DSS emphasizes access to and manipulation of a time series of internal company data and, sometimes, external data.
• A document-driven DSS manages, retrieves, and manipulates unstructured information in a variety of electronic formats.
• A knowledge-driven DSS provides specialized problem-solving expertise stored as facts, rules, procedures, or in similar structures.

Using scope as the criterion, Power differentiates enterprise-wide DSS and desktop DSS. An enterprise-wide DSS is linked to large data warehouses and serves many managers in the company. A desktop, single-user DSS is a small system that runs on an individual manager's PC.

Systems Development Life Cycle

SDLC, the Systems Development Life Cycle, or Software Development Life Cycle, relates to models or methodologies that people use to develop systems, generally computer systems. Computer systems have become more complex and usually (especially with the advent of Service-Oriented Architecture) link multiple traditional systems often supplied by different software vendors.
To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

Phases

SDLC adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. There are several SDLC Models in existence. The oldest model, that was originally regarded as “the SDLC” is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seems to vary between 4 and 7.
There is not a definitive correct model, but the steps can be characterized and divided as follows:

Initiation/Planning

To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team (Post & Anderson, 2006)

Requirements Analysis

The goal of systems analysis is to find out where the problem is in attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation. Analyses project goals, breaking down functions that need to be created, and attempts to engage users so that definite requirements can be defined.

Design

Functions and operations are described need to be detailed, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will be to describe the new system as a collection of modules or subsystems.

Build

Modular and subsystem programming code will be accomplished during this stage. This stage is intermingled with the next in that individual modules will need testing before integration to the main project.

Testing

The code is tested at various levels. Unit, system and user acceptance testing are often performed. This is a very grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of the Waterfall model, but usually some occurs at this stage.

Types of testing:

• Data set testing
• Unit testing
• System Testing
• Integration testing
• User acceptance

Implementation

The final stage of a project or the initial development, where the software is put into production and is used by the actual business.

Types of implementation:

• Documentation
• Training
• Parallel implementation
• Big-bang implementation (Direct cutover, Plunge)
• Phased implementation
• Pilot implementation

Operations and Maintenance

The life of the system which includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is a very important aspect of SDLC. As key personnel change position in the organization, new changes will be implemented, which will require system updates.

Software engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. It encompasses techniques and procedures, often regulated by a software development process, with the purpose of improving the reliability and maintainability of software systems. The effort is necessitated by the potential complexity of those systems, which may contain millions of lines of code.

The term software engineering was coined by Brian Randell and popularized by F.L. Bauer during the NATO Software Engineering Conference in 1968. The discipline of software engineering includes knowledge, tools, and methods for software requirements, software design, software construction, software testing, and software maintenance tasks. Software engineering is related to the disciplines of computer science, computer engineering, management, mathematics, project management, quality management, software ergonomics, and systems engineering.

In 2004, the U. S. Bureau of Labor Statistics counted 760,840 software engineers holding jobs in the U.S.; in the same time period there were some 1.4 million practitioners employed in the U.S. in all other engineering disciplines combined. Due to its relative newness as a field of study, formal education in software engineering is often taught as part of a computer science curriculum, and as a result most software engineers hold computer science degrees. The term software engineer is used very liberally in the corporate world. Very few of the practicing software engineers actually hold Engineering degrees from accredited universities. In fact, according to the Association for Computing Machinery, "most people who now function in the U.S. as serious software engineers have degrees in computer science, not in software engineering".

Ambiguity and controversy

Typical formal definitions of software engineering are:

• "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software".
• "an engineering discipline that is concerned with all aspects of software production"
• "the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines"

The term has been used less formally:

• as the informal contemporary term for the broad range of activities that were formerly called programming and systems analysis;
• as the broad term for all aspects of the practice of computer programming, as opposed to the theory of computer programming, which is called computer science;
• as the term embodying the advocacy of a specific approach to computer programming, one that urges that it be treated as an engineering discipline rather than an art or a craft, and advocates the codification of recommended practices.

Some people believe that software engineering implies a certain level of academic training, professional discipline, and adherence to formal processes that often are not applied in cases of software development. A common analogy is that working in construction does not make one a civil engineer, and so writing code does not make one a software engineer. It is disputed by some - in particular by the Canadian Professional Engineers Ontario (PEO) body, that the field is not mature enough to warrant the title "engineering". The PEO disputed that "software engineering" was not an appropriate name for the field since those who practiced in the field and called themselves "software engineers" were not properly licensed professional engineers, and that they should therefore not be allowed to use the name.

In each of the last few decades, at least one radical new approach has entered the mainstream of software development (e.g. Structured Programming, Object Orientation), implying that the field is still changing too rapidly to be considered an engineering discipline. Proponents argue that the supposedly radical new approaches are evolutionary rather than revolutionary.

Individual commentators have disagreed sharply on how to define software engineering or its legitimacy as an engineering discipline. David Parnas has said that software engineering is, in fact, a form of engineering. Steve McConnell has said that it is not, but that it should be. Donald Knuth has said that programming is an art and a science. Edsger W. Dijkstra claimed that the terms software engineering and software engineer have been misused, particularly in the United States.