Object-Oriented Software Development

The Object-Oriented Software Development Method (OOSD) includes object-oriented requirements analysis, as well as object-oriented design. OOSD is a practical method of developing a software system which focuses on the objects of a problem throughout development. OOSD's focus on objects early in the development, with attention to generating a useful model, creates a picture of the system that is modifiable, reusable, reliable, and understandable — the last perhaps most important because the picture of a software system created by a development method must be an effective device for communication among developers, customers, management, and quality-assurance personnel. Most object-oriented methods competing for the attention of the software developer actually apply traditional Structured Analysis (function-based), or variations of Structured Analysis, to requirements activity, and work through a transition process to an object-oriented design.  In these methods the developer begins with functionally-based requirements analysis, and only reaches an object-oriented design by the intermediary step of converting a traditional, functionally-decomposed data flow diagram (DFD) to an object-oriented DFD (or equivalent).  In this conversion process, objects are identified through a set of heuristics which group “transformations” in the DFD generated during requirements analysis. These methods carry a number of interesting but unfortunate burdens. Lower-level objects, which directly relate to real-world objects, are easily identified, but higher-level objects are generally more arbitrary, so that developers do not consistently identify a hierarchy of objects which achieves significant improvement in software engineering goals (e.g., reliability, maintainability, reusability). The heuristics for identifying objects usually relate the DFD transforms to the object that controls execution of an operation, rather than the object which “owns” the operation. These methods generally ignore the need to convert behavior descriptions of the DFD transforms into behavior descriptions of the objects. Finally, the use of Structured Analysis in an otherwise object-oriented approach complicates the tracing of requirements by forcing the developer to look first to DFD transforms and their behavior descriptions, and then to the objects.

For your references, please view:

Object-Oriented Programming by Wikepedia.

Object-Oriented Software Development, Analysis and Design. [PDF book}

What is Object-Oriented Software? by Terry Montlick.

Impact on Introducing Object Oriented Software Development Methodologies. by EuroSPI98.

THE CLEANROOM

The Cleanroom is a software development methodology that keep contaminants (software bugs) out of the product. The idea is to control cost by detecting bugs as early as possible, when they are less costly to remove. Rather than using natural languages like English, more formal notations are used to produce specifications on which all software design and requirements validation is based. Off-line review techniques are used to develop understanding of the software before it is executed. Software is intended to execute properly the first time. Programmers are not allowed to perform trial- and-error executions, though automation checks syntax, data flow, and variable types. Testing uses statistical examination to focus on the detection of the errors most likely to cause operational failures.

The general conclusion is that the resulting programs are more reliable than programs developed with the traditional lifecycle model, that the time required to produce a verified program is less than or the same as the time necessary to design, code, and debug a program, that the method of functional verification scales up to large programs, and that statistical quality control is superior to the time-honored technique of finding and removing bugs.

When to Use Cleanroom

Cleanroom can be used with waterfall, incremental, or spiral models to produce software of arbitrary size and complexity. Cleanroom has been successfully demonstrated with excellent results but widespread acceptance has not materialized due to its radical nonintuitive approach. Cleanroom provides higher quality software rather than direct productivity increases.

An organization beginning to use cleanroom need only have in place systematic design methods, formal inspection procedures, documented requirements in a natural language, developer-performed unit testing, configuration management of software after its release to the independent test organization, and ad hoc functional testing. The baseline process in Figure 5 represents such an organization. Cleanroom is not an all-or-nothing approach. The adjoining figure shows which cleanroom components are most appropriately implemented from the organization's baseline process.

Strengths of Cleanroom 

• Production of reliable software.
• Cleanroom may be gradually introduced to an organization.

Weaknesses of Cleanroom 

• Needs a complete set of requirements.
• Disciplined style may stifle creativity

View the Cleanroom Software Engineering Reference.

Software Prototyping

The idea behind software prototyping is to allow people who have some 'stake' or interest in a system to 'test drive' designs, rather than having to interpret those designs based on some other means. Though not all prototypes are interactive, the most useful application of prototyping is based upon providing a similation of some behaviour and functionality.

One of the best ways to test the usability of a product while there is still time to make changes is to develop a rapid prototype. The idea is to build a mock-up of the product, which simulates the look and feel of the interface and brings many of the complex interaction problems out in the open.

Once such a mock-up exists, you can show it to customers to determine if it was really what they had in mind. If the prototype does not meet their expectations, it is early enough in the development cycle to redesign and still make the ship date.

A prototype allows you to find out what you need to change. Just run a usability study with customers on the prototype's user interface, and you can have your answer in time to change the design if necessary before the product is fully developed.

Developing a software prototype frequently leads the software engineer to a greater understanding of the application requirements, thus improving the system design.

Prototyping is a highly recommended approach, because review of the prototype enables users, funders, project managers, and developers to agree on how an application should look (e.g. screen layouts, reports) and behave (e.g. flow of control, error handling). In some cases, a prototype enables a software engineer to confirm that a particular requirement, such as performance, can be met.

Details about SOFTWARE PROTOTYPING can be found at Reynard Thomson Website.

The Waterfall Model (Software Development Methodology)

The Waterfall Model, otherwise known as the Linear Sequential Model, is an approach to development that emphasizes completing a phase of the development before proceeding to the next phase. In conjunction with certain phase completions, a baseline is established that "freezes" the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change. The graphic representation of these phases in software development resembles the downward flow of a waterfall.

Each box in the above figure represents a phase. Output from each phase includes documentation. Transition from phase to phase is accomplished by holding a formal review that is attended by the different parties concerned. These reviews provide all parties insight into the system developer's progress. At critical points on the waterfall model, baselines are established, the last of which is the product baseline. This final baseline is accompanied by audits.

The Waterfall Model is best suited for projects that includes hardware as its major component. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

But there are differences between hardware and software that the waterfall model does not address. Unlike hardware, software requires no fabrication. "Once the drawings and models (programs) are complete, the final product exists." Using the analogies of house building and sculpting to make the point, hardware projects begin with a good understanding of the requirements, and that once fabrication begins, changes are restricted to the cosmetic and minor items. Sculpting can be a less rigid exercise in the sense that moldable clay can be added, removed, or otherwise rearranged. The problem with the waterfall model is that the flow is optimized for hardware, thereby neglecting the essential characteristics of software.

Many software development methodologies have evolved from attempts to optimize the waterfall model for software. For example, software prototyping helps provide the complete understanding of the requirements that is typical of hardware production -- which understanding is critical to the waterfall model. Two other examples are the incremental and spiral models, which allow the phases identified above to be revisited repeatedly prior to declaring a product to be final. Such revisiting is very costly in hardware development and is to be used sparingly according to the waterfall model.

For an in-depth study of the waterfall model, click here.

Testing

A software or system which is not tested would be of poor quality. This is because this is the phase where system developed would be tested and reports are prepared about bugs or errors in system. To do this testing phase there are different levels and methods of testing like unit testing, system test and so on. Based on the need the testing methods are chosen and reports are prepared about bugs. After this process the system again goes to development phase for correction of errors and again tested. This process continues until the system is found to be error free. To ease the testing process debuggers or testing tools are also available.

The process of performing a variety of tests on a system to explore functionality or to identify problems. System testing is usually required before and after a system is put in place. A series of systematic procedures are referred to while testing is being performed. These procedures tell the tester how the system should perform and where common mistakes may be found. Testers usually try to "break the system" by entering data that may cause the system to malfunction or return incorrect information. For example, a tester may put in a city in a search engine designed to only accept states, to see how the system will respond to the incorrect input.

Code Generation

This is the programming part.  Source codes are generated by the programmer under the guidance of an experienced systems analyst.  The system specifications provided in the System Design are carried out and translated into codes, in a programming language understood by everybody in the project team.

In computer science, code generation is the process by which a compiler's code generator converts some internal representation of source code into a form (e.g., machine code) that can be readily executed by a machine (often a computer).

Sophisticated compilers typically perform multiple passes over various intermediate forms. This multi-stage process is used because many algorithms for code optimization are easier to apply one at a time, or because the input to one optimization relies on the processing performed by another optimization. This organization also facilitates the creation of a single compiler that can target multiple architectures, as only the last of the code generation stages (the backend) needs to change from target to target.

The input to the code generator typically consists of a parse tree or an abstract syntax tree. The tree is converted into a linear sequence of instructions, usually in an intermediate language such as three address code. Further stages of compilation may or may not be referred to as "code generation", depending on whether they involve a significant change in the representation of the program.

System Analysis and Design

This is an important phase in system development .Here analysis is made on the design of the system that is going to be developed. In other words database design, the design of the architecture chosen, functional specification design, low level design documents, high level design documents and so on takes place. Care must be taken to prepare these design documents because the next phases namely the development phase is based on these design documents. If a well structured and analyzed design document is prepared it would reduce the time taken in the coming steps namely development and testing phases of the software development life cycle.

structured systems analysis A specific technique for systems analysis that covers all activities from initial understanding of the problem through to specification and high-level design of the software system. The technique embodies four main concepts: dataflow diagrams, a data dictionary, data store structuring, and process logic representations.

The dataflow diagrams show the various processing elements in the system, and the dataflows between these processing elements and the major stores of data within the system. The processing elements are described in nonprocedural terms, typically using natural language, and a processing element from one diagram may be decomposed onto further diagrams to show greater levels of detail. A data dictionary is used to record all the various data items in the system, the constraints upon these data items, and the processing elements by which they are accessed. As the decomposition proceeds so both the data stores and the actions of the processing elements are defined in more detail. The data store structuring techniques are based upon the relational model of data and show how each data store is accessed and organized. The algorithms employed by the processing elements are defined by use of process logic representations, typically program design languages, decision tables, or “structured” natural language.

Two similar versions of structured systems analysis were developed separately by Gane and Sarson and by De Marco. The technique is intended primarily for use in traditional DP system development.