Prototyping model and Object oriented model

The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation
Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage.
After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation.
The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back. There is now a new generation of tools called Application Simulation Software which help quickly simulate application before their development.

Advantages of prototyping
May provide the proof of concept necessary to attract funding
Early visibility of the prototype gives users an idea of what the final system looks like
Encourages active participation among users and producer
Enables a higher output for user
Cost effective (Development costs reduced)
Increases system development speed
Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities
Helps to refine the potential risks associated with the delivery of the system being developed

Disadvantages of prototyping
User’s expectation on prototype may be above its performance
Possibility of causing systems to be left unfinished
Possibility of implementing systems before they are ready
Producer might produce a system inadequate for overall organization needs
User can get too involved where as the program can not be to a high standard
Structure of system can be damaged since many changes could be made
Producer might get too attached to it (might cause legal involvement)
Not suitable for large applications

Electronics prototyping
In electronics, prototyping means building an actual circuit to a theoretical design to verify that it works, and to provide a physical platform for debugging it if it does not.
The prototype is often constructed using techniques such as wire wrap or using Vero board or breadboard, that create an electrically correct circuit, but one that is not physically identical to the final product

mass produce custom printed circuit boards than these other kinds of prototype boards. This is for the same reasons that writing a poem is fastest by hand for one or two, but faster by printing press if you need several thousand copies.
[Edit] Rapid Electronics prototyping
The proliferation of quick-turn pub fob companies and quick-turn pub assembly houses has enabled the concepts of rapid prototyping to be applied to electronic circuit design. It is now possible, even with the smallest passive components and largest fine-pitch packages, to have boards fobbed and parts assembled in a matter of day


Strength of object oriented model.
Object-oriented models have rapidly become the model of choice for programming most new computer applications. Since most application programs need to deal with persistent data, adding persistence to objects is essential to making object-oriented applications useful in practice. There are three classes of solutions for implementing persistence in object-oriented applications: the gateway-based object persistence approach, which involves adding object-oriented programming access to persistent data stored using traditional non-object-oriented data stores, the object-relational database management system (DBMS) approach, which involves enhancing the extremely popular relational data model by adding object-oriented modeling features, and the object-oriented DBMS approach (also called the persistent programming language approach), which involves adding persistence support to objects in an object-oriented programming language. In this paper, we describe the major characteristics and requirements of object-oriented applications and how they may affect the choice of a system and method for making objects persistent in that application. We discuss the user and programming interfaces provided by various products and tools for object-oriented applications that create and manipulate persistent objects. In addition, we describe the pros and cons of choosing a particular mechanism for making objects persistent, including implementation requirements and limitations imposed by each of the three approaches to object persistence previously mentioned. Given that several object-oriented applications might need to share the same data, we describe how such applications can interoperate with each other. Finally, we describe the problems and
solutions of how object-oriented applications can coexist with non-object-oriented (legacy) applications that access the same data.


Strength and weakness of object oriented model
Benchmarks between Odom’s and RDBMS have shown that ODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and
navigational access to data is usually implemented very efficiently by following pointers.[3]
Critics of Navigational Database-based technologies like ODBMS suggest that pointer-based techniques are optimized for very specific "search routes" or viewpoints. However, for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigation appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses. (However, it may be possible to apply generic reordering and optimizations of pointer routes in some cases).
Other things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world including but not limited to industry standard connectivity, reporting tools, OLAP tools and backup and recovery standards. Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact that some Odom’s fully support SQL in addition to navigational access, e.g. Objectivity/SQL++, Matisse, and Intersystem CACHÉ. Effective use may require compromises to keep both paradigms in sync.


In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it available only through a published set of interface methods, and the assumption underlying much database technology, which is that data should be accessible to queries based on data content rather than predefined access paths. Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint. This is one of the many impedance mismatch issues surrounding OOP and databases.
Although some commentators have written off object database technology as a failure, the essential arguments in its favor remain valid, and attempts to integrate database
Functionality more closely into object programming languages continue in both the research and the industrial communities

Investigate the prototyping model and any object-oriented model.
Discussion, see Object-oriented analysis and design and Object-oriented programming. The description of these Objects is a Schema.
As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like Name, Birthdates, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An Employee Method may be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many notations has been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.

An informal description or a Schema notation is translated by the programmer or a Computer-Aided Software Engineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports Object-Oriented Programming (or a Class Type), a Declarative Language or into a Database schema.

Strengths and Weakness of SDLC Models

Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Strengths
· Simple and easy to use.
· Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
· Phases are processed and completed one at a time.
· Works well for smaller projects where requirements are very well understood.

Weaknesses
· Adjusting scope during the life cycle can kill a project
· No working software is produced until late during the life cycle.
· High amounts of risk and uncertainty.
· Poor model for complex and object-oriented projects.
· Poor model for long and ongoing projects.


V-Shaped Model
Strengths
· Simple and easy to use.
· Each phase has specific deliverables.
· Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
· Works well for small projects where requirements are easily understood.

Weaknesses
· Very rigid, like the waterfall model.
· Little flexibility and adjusting scope is difficult and expensive.
· Software is developed during the implementation phase, so no early prototypes of the software are produced.
· Model doesn’t provide a clear path for problems found during testing phases


Incremental Model
Stengths
·Generates working software quickly and early during the software life cycle.
·More flexible – less costly to change scope and requirements.
·Easier to test and debug during a smaller iteration.
·Easier to manage risk because risky pieces are identified and handled during its iteration.
·Each iteration is an easily managed milestone.

Weaknesses
·Each phase of an iteration is rigid and do not overlap each other.
·Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.


Spiral Model
The spiral model is the most generic of the models. Most life cycle models can be derived as special cases of the spiral model. The spiral uses a risk management approach to software development. Some advantages of the spiral model are:
· defers elaboration of low risk software elements
· incorporates prototyping as a risk reduction strategy
· gives an early focus to reusable software
· accommodates life-cycle evolution, growth, and requirement changes
· incorporates software quality objectives into the product
· focus on early error detection and design flaws
· sets completion criteria for each project activity to answer the question: "How much is enough?"
· uses identical approaches for development and maintenance can be used for hardware-software system develop
Strengths
· High amount of risk analysis
· Good for large and mission-critical projects.
· Software is produced early in the software life cycle.

Weaknesses
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

Evolutionary Prototyping
Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration
Strengths
· Customers can see steady progress
· This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one fully understands the application area

Weakness
· It is impossible to know at the outset of the project how long it will take.
· There is no way to know the number of iterations that will be required.
Evolutionary Prototyping Summary The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.

Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Strengths
· No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities
· Requires little experience

Weakness
· Dangerous.
· No means of assessing quality or identifying risks.
· Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out.
Code-and-Fix Summary Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes

Weakness
· Won't be able to predict the full range of functionality.
Design-to-Schedule SummaryIn design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features. Leave the lower priority features for later

Staged Delivery
Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design, coding, testing and deployment.
Strengths
· Can put useful functionality into the hands of customers earlier than if the product were delivered at the end of the project.

Weakness
· Doesn't work well without careful planning at both management and technical levels

Staged Delivery Summary For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all dependencies between different components of the system

Evolutionary Delivery
Evolutionary delivery straddles evolutionary prototyping and staged delivery
Strengths
Enables customers to refine interface while the architectural structure is as

Weakness
Doesn't work well without careful planning at both management and

Evolutionary Delivery Summary For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions which are unlikely to be changed by customer feedback

Design-to-Schedule
Like staged delivery, design-to-schedule is a staged release model. However, the number of stages to be accomplished are not known at the outset of the project.
Strengths
· Produces date-driven functionality, ensuring there is a product at the critical date.
· Covers for highly suspect estimates