Info Sec in the SDLC Brochure (Adobe Acrobat, approximately 2.5 mb)

Many SDLC models exist that can be used by an organization to effectively develop an information system. A traditional SDLC is a linear sequential model. This model assumes that the system will be delivered near the end of its life cycle. More complex models have been developed to address the evolving complexity of advanced and large information system designs.

A general SDLC includes five phases: initiation, acquisition/development, implementation/assessment, operations/maintenance, and sunset (disposition). Each of the five phases includes a minimum set of security tasks needed to effectively incorporate security in the system development process. Including security early in the information SDLC will usually result in less expensive and more effective security than adding it to an operational system.

The following questions should be addressed in determining the security controls that will be required for a system:

How critical is the system in meeting the organization's mission?
What are the security objectives required by the system, e.g., integrity, confidentiality, and availability?
What regulations and policies are applicable in determining what is to be protected?
What are the threats that are applicable in the environment where the system will be operational?
http://csrc.nist.gov/SDLCinfosec/
Systems Life Cycle

Site Map: [ Project Page | Systems Life Cycle | ERP | ERP Methodologies | Systems Life Cycle vs ERP]

(Source: Management Information Systems Organization and Technology 4th Edition, Kenneth C. Laudon and Jane Price Laudon)

The traditional Systems Life Cycle is the oldest method for building information systems. This methodology assumes that an information system has a life cycle similar to that of any living organism, with a

BEGINNING > MIDDLE > END.

The Systems Life Cycle methodology has six stages. It partitions the system development process into distinct stages and develops an information system sequentially, stage by stage. The six stages and a detail definition of each are as follows:

Stage 1 - Project Definition
Determines whether the organization has a problem and whether that problem can be solved by building a new information system. The following questions are answered: Why do we need a new system project? What do we want to accomplish? If a project is called for, the project definition stage identifies general objectives, specifies the scope of the project and develops a project plan that can be shown to management.

Stage 2 - Systems Study
This stage analyzes the problems of the existing system (manual or automated) in detail, identifies objectives to be attained by a solution to these problems, and describes alternative solutions. The systems study phase examines the feasibility of each solution alternative for review by management. The following questions are answered:

What do the existing systems do?
What are their strengths, weaknesses, trouble spots, and problems?
What should a new or modified system do to solve these problems?
What user information requirements must be met by the solution?
What alternative solution options are feasible?
What are their costs and benefits?

Answering these questions requires extensive information gathering and research; sifting through documents, reports, and work papers produced by existing systems; observing how these systems work; polling users with questionnaires; and conducting interviews. All of the information gathered during the system study phase will be used to determine information system requirements. The systems study stage describes in detail the remaining life cycle activities and the tasks for each phase.

Stage 3 - Design
This stage produces the logical and physical design specifications for the solution. Design and documentation tools (flow diagrams, structure charts, system flowcharts, etc.) are used to develop formal specifications.

Stage 4 - Programming
This stage translates the design specifications produced during the design stage into software program code. Specifications are prepared for each program in the system which describes what each program will do, the type of programming language to be used, inputs, outputs, processing logic, processing schedules, and control statements . Customized program code is written generally using a 3rd or 4th generation programming language.

Stage 5 - Installation
Consists of the final steps to put the new or modified system into operation: testing, training, and conversion. The software is tested to ensure that it performs properly from both a technical and a functional business standpoint. A formal conversion plan provides a detailed schedule of all the activities required to install the new system, and the old system is converted to the new one.

Stage 6 - Post Implementation
Consists of using and evaluating the system after it is installed and is in production. It also includes updating the system to make improvements. A formal post-implementation audit is done to determine how well the new system has met its original objectives and whether any revisions or modifications are required. After the system has been fine tuned, it will need to be maintained while it is in production to correct errors, meet requirements, or improve processing efficiency.

Division of Labor
This methodology has a formal division of labor between end users and information systems specialists. Technical specialists such as systems analysts and programmers are responsible for systems analysis, design and implementation work; End-users are limited to providing information requirements and reviewing the work of the technical staff.

Outputs and Signoff
A product or output is produced at each stage of the life cycle and is the basis for sign-off agreements. The product or output for the six stages are as follows:
STAGE (Output or Product)
1. Project Definition (Project proposal report)
2. Systems Study (System proposal report)
3. Design (Design specifications
4. Programming (Software code)
5. Installation (System performance tests)
6. Post Implementation (Post implementation audit)

Suitability and Limitations
The Systems Life Cycle methodology is usually used for building large transaction processing systems (TPNS) and management information systems (MIS) where requirements are highly structured and well-defined. It also remains appropriate for complex technical systems requiring rigorous and formal requirements analysis, predefined specifications, and tight controls over the systems-building process (space launches, air traffic control, and refinery operations). This methodology has serious limitations and is not well suited for most of the small desktop systems that dominate during the 1990s and beyond.

Resource Intensive
This methodology is resource intensive in that a tremendous amount of time must be spent gathering information and preparing specifications and sign-off documents. It may take years before a system is finally installed. If development time is too prolonged, the information requirements may change before the system is operational. The system that takes many years and dollars to build may be obsolete while it is still on the drawing board.

Inflexible and Inhibits Change
This methodology does not allow for revisions to the system to ensure that requirements are met. Whenever requirements are incorrect, or an error is encountered, the sequence of life cycle activities can be repeated. This may cause the generation of volumes of additional documents and substantially increase development time and costs. Because of the time and cost to repeat the sequence of life cycle activities, the methodology encourages freezing of specifications early in the development process. This means that changes cannot be made. Once users approve specification documents, the specifications are frozen. Because users sometimes have a problem visualizing a final system from the specification documents, it is common for them to sign-off on them without fully comprehending their contents. They sometimes learn during programming and testing that the specifications are incomplete or not what they had in mind. Proper specifications cannot always be captured the first time around, early enough in the life cycle when they are easy to change.

Suited to Decision-Oriented Applications
Decision making can be rather unstructured and fluid. Requirements constantly change or decisions may have no well-defined models or procedures. Decision makers often cannot specify their information needs in advance. This high-level of uncertainty cannot be easily accommodated by this methodology.
http://isds.bus.lsu.edu/cvoc/learn/bpr/cprojects/spring1998/erp/page1.html
CASE: Acronym for computer-aided software engineering, computer-aided systems engineering. Software used for the automated development of systems software, i.e. , computer code. Note 1: CASE functions include analysis, design, and programming. Note 2: CASE tools automate methods for designing, documenting, and producing structured computer code in the desired programming language.
http://www.its.bldrdoc.gov/fs-1037/dir-006/_0869.html
What is a CASE Environment?

Our Definition of CASE
Many definitions and descriptions of CASE exist. We choose a broad definition, perhaps the most straightforward one possible:

CASE is the use of computer-based support in the software development process.
This definition includes all kinds of computer-based support for any of the managerial, administrative, or technical aspects of any part of a software project.

What Is a CASE Tool?
Since the early days of writing software, there has been an awareness of the need for automated tools to help the software developer. Initially the concentration was on program support tools such as translators, compilers, assemblers, macro processors, and linkers and loaders. However, as computers became more powerful and the software that ran on them grew larger and more complex, the range of support tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers, code analyzers, and program-pretty printers.

As computers became more reliable and in greater use, the need for a broader notion of software development became apparent. Software development came to be viewed as:

A large-scale activity involving significant effort to establish requirements, design an appropriate solution, implement that solution, test the solution's correctness, and document the functionality of the final system.

A long-term process producing software that requires enhancement through out its lifetime. The implications of this are that the structure of the software must enable new functionality to be added easily, and detailed records of the requirements, design, implementation, and testing of the system must be kept to aid maintainers of the software. In addition, multiple versions of all artifacts produced during a project must be maintained to facilitate group development of software systems.

A group activity involving interaction among a number of people during each stage of its life. Groups of people must be able to cooperate, in a controlled manner, and have consistent views of the state of the project.
This view of "programming in the large" resulted in a wide range of support tools being developed. Initially, the tools were not very sophisticated in their support. However, two important advances had the effect of greatly improving the sophistication of these tools:

Research in the area of software development processes gave rise to a number of software design methods (e.g., Jackson Structured Programming, the Yourdon Method) that could be used as the basis for software development. These methods were ideally suited to automated tool support in that they required step-by-step adherence to methods, had graphical notations associated with them, and produced a large number of artifacts (e.g., diagrams, annotations, and documentation) that needed to be recorded and maintained.

.....personal workstations and personal computers. These machines have relatively large memory storage capacities, fast processors, and sophisticated bit-mapped graphics displays that are capable of displaying charts, graphical models, and diagrams.

We refer to all of the above tools as CASE tools and posit the following definition:

A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.
Other authors have attempted to make finer-grained distinctions between differ ent classes of CASE tools along a number of dimensions. The most common distinctions are:

Between those tools that are interactive in nature (such as a design method support tool) and those that are not (such as a compiler). The former class are sometimes called CASE tools, while the latter class are called development tools.

Between those tools that support activities early in the life cycle of a soft ware project (such as requirements and design support tools) and those that are used later in the life cycle (such as compilers and test support tools). The former class are sometimes called front-end CASE tools, and the latter are called back-end CASE tools.

Between those tools that are specific to a particular life-cycle step or domain (such as a requirements tool or a coding tool) and those that are common across a number of life-cycle steps or domains (such as a documentation tool or a configuration management tool). The former class are sometimes called vertical CASE tools, while the latter class are called horizontal CASE tools.
Unfortunately, all these distinctions are problematic. In the first case, it is difficult to give a simple and consistent definition of `interactive' that is meaningful. For example, some classes of compilers prompt the user for information. In the second and third cases, there is an assumption about the methods and approaches in use (e.g., object-oriented software development, or prototype-oriented development), hence our use of the broader, inclusive definition of a CASE tool.

What Is a CASE Environment?
The first generation of CASE tool developers concentrated to a large extent on the automation of isolated tasks such as document production, version control of source code, and design method support. While successes have been achieved in supporting such specific tasks, the need for these `islands of automation' to be connected has been clearly recognized by many first generation CASE tool users. For example, a typical development scenario requires that designs be closely related to their resultant source code, that they be consistently described in a set of documentation, and that all of these artifacts be under centralized version control. The tools that support the individual tasks of design, coding, documentation, and version control must be integrated if they are to support this kind of scenario effectively.

In fact, such tools are more often used as components in a much more elaborate software development support infrastructure that is available to software engineers. A typical CASE environment consists of a number of CASE tools operating on a common hardware and software platform. Also note that there are a number of different classes of users of a CASE environment. Some users, such as software developers and managers, wish to make use of CASE tools to support them in developing application systems and monitoring the progress of a project. On the other hand, tool integrators are responsible for ensuring that the tools operate on the software and hardware platform available, and the system administrator's role is to maintain and update the hardware and software platform itself.

Also note that software developers, tool integrators, and system administrators interact with multiple CASE tools and environment components that form the software and hardware platform of the CASE environment. It is these interactions, among the different CASE environment components and between users and those components, that are the key elements of a CASE environment. In many respects the approach toward the management, control, and support of these interactions distinguishes one CASE environment from another. We can define a CASE environment by emphasizing the importance of these interactions:

A CASE environment is a collection of CASE tools and other components together with an integration approach that supports most or all of the interactions that occur among the environment components, and between the users of the environment and the environment itself.
The critical part of this definition is that the interactions among environment components are supported within the environment. What distinguishes a CASE environment from a random amalgamation of CASE tools is that there is some thing that is provided in the environment that facilitates interaction of those tools. This `something' may be a physical mechanism such as a shared database or a message broadcast system, a conceptual notion such as a shared philosophy on tool architectures or common semantics about the objects the tools manipulate, or some combination of these things.

The range of possible ways of providing the `glue' that links CASE tools together inevitably leads to a spectrum of approaches to implementing a CASE environment. One of the main points we make in this book is that there are many ways to build a CASE environment. While many people concentrate on the selection of CASE tools and components when assembling a CASE environ ment, they largely ignore the need to support the interactions among those components. We concentrate less on which components should be chosen, and much more on how the selected components can be made to work together effectively. Whether a chosen approach to component interaction is appropriate in a given context will depend on many overlapping factors: the needs of the organization in question, the available resources, and so forth. A detailed assessment of these related factors and constraints is necessary to determine the CASE environment most suited to the problem at hand.
http://www.sei.cmu.edu/legacy/case/case_whatis.html
Introduction and Definition
In 1891, Mr. Henry Ford presented his wife Clara with a design for an internal combustion engine, drawn on the back of a piece of sheet music. “Crazy” Henry, as some of his neighbors called him, was seemingly always consumed in his work of developing what he had dreamed of as a child, a “horseless carriage.” By 1908, Ford saw his dream come to fruition when he completed one of the most important prototypes in this modern era- the Model T. From his first drawing on the back of a piece of sheet music, to the introduction of the Model T, Henry Ford took full advantage of one of the most important aspects of new product design and innovation- prototyping.

Prototyping, according to Webster’s dictionary, can officially be defined as “an original model after which other similar things are patterned.” This is a vague definition, but prototyping in general is a rather vague concept. This is because it can be applied to many different things and ideas. For example, Ford’s simple drawing of an internal combustion engine can be considered as much of a prototype as his first completed Model T. The definition of a prototype can also change quite a bit depending on what industry is being spoken of. According to OCLC online, prototyping can be compared to a rough draft of a document. “It still needs to be polished, but allows you to begin solidifying ideas, correcting major errors, and even start over without a lot of lost time.”

Prototyping generally is broken up into two broad categories: High-fidelity and low-fidelity prototypes. Which one of these you use depends on where you are in the design process and what industry is involved. A low-fidelity (also known as lo-fi) prototype is a quick and dirty mockup that is cheap, easily changed, and can be thrown away without complaint. The goal of such a prototype is to create something as quickly as possible that will elicit user feedback. A high-fidelity (also known as hi-fi) prototype, on the other hand, is much closer to the actual product in look and feel and requires much more of an investment to produce.

How to Use Prototyping
When learning how to use prototyping, it is essential to learn of the different methods associated with it. Probably the most common lo-fi prototype is that of the paper prototype. The paper prototype is usually considered to be the cheapest and quickest way to develop a prototype. This process can be as simple as using a pencil and a piece of paper to draw out the mockup (or model) of the prototype. The idea is to get the prototype on paper so the decision-makers of the company can evaluate it. They can then determine if the prototype is something that the company would want to pursue. The paper prototype is ideal because the company can see early on in the process if the prototype is viable without spending a lot of time and money. Also the design teams feel less pressure in these early stages of prototype development, which usually results in better ideas.

Perhaps the most common way of prototyping these days is by way of CAD (Computer Aided Design), which is also another form of a paper prototype. This process involves using some sophisticated computer models to come up with a working prototype. These CAD prototypes are most prevalent in the automobile industry, where today’s cars are designed entirely by computer, allowing design attributes to be shared simultaneously by every department involved in the product design process. With the sharing of these designs comes the advantage of having everyone involved and giving input on the prototype. Probably the most distinct advantage of prototyping in this fashion is the flexibility it provides to the designers who can work together to perfect the prototype before any money is spent to bring it to life.

The third form of prototyping is rapid prototyping. Rapid prototyping automates the fabrication of a prototype part from a 3-Dimensional CAD drawing. Rapid prototyping is very effective because it aids in the process of guiding a product from concept to market quickly and inexpensively. Whereas conventional prototyping methods may take weeks or even months depending on the process used, the typical turnaround for a rapid prototype part can take a few days. Rapid prototyping also reduces the amount of defects in products and reduces risk from the company’s perspective.

The use of these prototyping methods changes from industry to industry, but there are always some basic steps that need to be followed when developing a prototype. First, you need to develop a plan for your prototype and come up with some goals about how you are going to accomplish that plan. Next is the selection of the actual design process, or in other words, what type of prototype will be constructed. Once the decision is made on the design process, the actual prototype is then constructed and analyzed to see if it is feasible. If the prototype is considered feasible, it is then rolled-out and physically produced. The final stage is the evolution of the design, where improvements and changes are continuously made to the final prototype.

Example Where Prototyping is Used

In almost every industry it is necessary in the design process to produce a prototype of the product before the final product is ever produced. This is especially important in the automobile industry, where Ford Motor Company has mastered the use of CAD programs to develop functional prototypes. Ford’s global network of research and development facilities can be found all over the world and are connected via satellite links, undersea cables, and land lines purchased from telecommunication carriers. By staying connected, a 3-D drawing of a new-car design can be sent from site to site, where colleagues at each site can look at the prototype simultaneously and discuss changes. The image can be changed and modified in any way imaginable, and then is sent to a computerized milling machine in Turin, where a clay or plastic foam prototype can be produced in a few hours.

With such a system, Ford has created the possibility of getting instant feedback from its numerous departments around the world and creating a better-quality prototype that is less expensive. Forty percent of the development costs of a new car are spent modifying the design after production has begun. Ford hopes this worldwide network will cut down on the number of changes in a new car’s initial design and shorten the design cycle to two years or less.

Where to Get More Information on Prototyping

Although the basics of prototyping were covered in this paper, there is still much that can be learned about this ever-changing process. Here are some web sites and additional sources that helped me.
http://www.freequality.org/beta%20freequal/fq%20web%20site/Training/Classes%20Fall%202002/Prototyping.doc