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.

Data Warehouse

A data warehouse is a repository of an organization's electronically stored data. Data warehouses are designed to facilitate reporting and analysis.

This classic definition of the data warehouse focuses on data storage. However, the means to retrieve and analyze data, to extract, transform and load data, and to manage the data dictionary are also considered essential components of a data warehousing system. Many references to data warehousing use this broader context. Thus, an expanded definition for data warehousing includes business intelligence tools, tools to extract, transform, and load data into the repository, and tools to manage and retrieve metadata.

In contrast to data warehouses are operational systems which perform day-to-day transaction processing.

Benefits of data warehousing

Some of the benefits that a data warehouse provides are as follows:

• A data warehouse provides a common data model for all data of interest regardless of the data's source. This makes it easier to report and analyze information than it would be if multiple data models were used to retrieve information such as sales invoices, order receipts, general ledger charges, etc.
• Prior to loading data into the data warehouse, inconsistencies are identified and resolved. This greatly simplifies reporting and analysis.
• Information in the data warehouse is under the control of data warehouse users so that, even if the source system data is purged over time, the information in the warehouse can be stored safely for extended periods of time.
• Because they are separate from operational system, data warehouses provide retrieval of data without slowing down operational systems.
• Data warehouses facilitate decision support system applications such as trend reports (e.g., the items with the most sales in a particular area within the last two years), exception reports, and reports that show actual performance versus goals.
• Data warehouses can work in conjunction with and, hence, enhance the value of operational business applications, notably customer relationship management (CRM) systems.