New Software Model

I have developed a new Hybrid SDLC model. I got positive acknowledgement from R.S Pressman( Author Software Engineering a Practioner's Approach)

I did case study on existing models amd then I have presented my model PBSD below

I need support to enhahce the model and also acknowledgements on the model

Case Studies Report on Software Models
---------------------------------------

Software Development Models
----------------------------

Over the years, various models have emerged to support the development of high-quality software products. A few of the most widely adopted models are presented below. Software development models chart out plans on how the project needs to be executed, within the given span of time. The model also comprises of sketched requirements from the customer including the quality variables. The model also contains the analysis of the requirements containing information like what the proposed system needs to do, study of the existing system, customer interview, verifying requirements specification, etc.

The commonly available software development models are Waterfall, RAD, Spiral, Incremental, Component based etc.

The Water-fall Model
--------------------

The waterfall model was first put forward by Royce. First requirements are determined and checked by the clients and members of SQA group. Then the specifications for the products are drawn up; that is, a document is produced stating what the product is to do.
This phase is complete when the document has been checked by the SQA group and approved by the client. Once the client has signed off on the specification document, the planning phase commences and the detailed timetable for developing the software is drawn up. This plan is also checked by the SQA group.
When the client has approved the developers' duration and cost estimates for the product, the design phase begins. Specification document that describes what the product is to do, the design document describe how the product is to do it. During the design phase it is sometimes apparent that there is a fault in the specification document. The presence of incompleteness, contradictions, or ambiguities necessitates a revision of the specification document before the software development process can continue.
When the developers are finally satisfied, the design documents are handed over to the programmers for implementation.
A critical point regarding the waterfall model is that no phase is complete until the documentation for that phase has been completed and the products of that phase have been approved by the SQA group.

Analysis of Water-fall model
-----------------------------

The waterfall model has many advantages, including the enforced disciplined approach, the stipulation and documentation be provided at each phase, and the requirement that the products of each phase are carefully checked by SQA group. Inherent in every phase of waterfall model is testing.
However the fact that waterfall model is documentation driven can also be an disadvantage. To see this, consider the following two somewhat bizarre scenarios. First, Kiran and Ram decide to build a house. They consult with an architect. Instead of showing them sketches, plans, and perhaps a model, the architect gives them a 20 page single-spaced typed document describing the house in highly technical terms. The first time the client sees a working product is only after the entire product has been coded. Small wonder that software developers live in fear of the sentence "I know this is what I asked for, but it isn't really what I wanted." The specifications exist only on paper; the client cannot really understand what the product itself will be like. The waterfall model, depending as it really does so crucially on written specifications can lead to construction of products that simply do not meet the client real needs.
In fairness it should be pointed out that, Just as an architect can help the client understand what is to be built by providing models, sketches and plans so the software engineer can use graphical techniques, such as data flow diagrams to communicate with the client. The problem is that graphical aids do not descried how the finished product will work. For example, there is a considerable difference between a flowchart (a diagrammatic description of the product) and the working product itself. Working version of program is not available until late in the project time span. And it is often difficult for the customer to state all the requirements explicitly. Changes can cause confusion as the project team proceeds

Rapid prototyping Model
------------------------

A rapid prototype is a working model that is functionally equivalent to a subset of the product. For example if the target product is to handle accounts payable, accounts receivable and warehousing, then the rapid prototype might consist of a product that performs the screen handling for data capture and print the reports but does no file updating or error handling.
The first step in the rapid prototyping life-cycle model is to build a rapid prototype and to let the client and future users interact with the rapid prototype and experiment with it. Because the working rapid prototype has been validated through interaction with the client, it is reasonable to expect that the resulting specification document will be correct. Even though the rapid prototype has(quite rightly) been hurriedly assembled, the design team can gain insights from it-at worst they will be of the "how not to do it".

Analysis of Rapid prototype Model
---------------------------------

The sole use of the rapid prototype is to determine what is the client's real needs are; once this has been determined, the rapid prototype is effectively discarded. For this reason, the internal structure of is not relevant. What is important is that the prototype be built rapidly and then modified to reflect the client's needs. Thus speed is the essence.

Integrating waterfall and Rapid Prototyping Model
-------------------------------------------------

Rapid prototyping can be used as requirement analysis technique; In other words, the first step is to build a rapid prototype in order to determine the client's real needs and then to use rapid prototype as the input to the waterfall model
Some organizations are reluctant to use the rapid prototyping approach because the risks involved in using any new technology. Introducing rapid prototyping into the organization as the front end to the waterfall model gives management the opportunity to access the technique while minimizing the associated risk.

Incremental Model
------------------

Software is built, not written. That is to say, software is constructed step by step, in the same way that a built is constructed. While a software product is in the process of being developed, each step adds to what has gone before. One day the design is extended; the next day another module is coded. The construction of complete product proceeds incrementally in this way until completion.
The product is designed, implemented, integrated and tested as a series of incremental builds, where a build consist of code pieces from modules interacting to provide a specific functional capability.
For example, the product is to control a nuclear submarine, then the navigation system could constitute a build, as could the weapons control system. In an operating system, the scheduler could be a build, and so could the file management system. At each stage of the incremental model a new build is coded and integrated into the structure that is tested as a whole.

Analysis of Incremental Model
------------------------------

Incremental model does deliver an operational quality product at each stage, but one that satisfies only a subset of the client's requirements. Incremental model reduces the traumatic effect for imposing a completely new product on the client organization. With the incremental model, portions of the total product might be available within weeks, whereas the client generally waits months or years to receive a product built using the waterfall or rapid prototyping model.
A difficulty with the incremental model is that each additional build somehow has to be incorporated into the existing structure without destroying what has been built to date.
In a sense, the incremental model is a contradiction in terms, requiring the developer to view the product as a whole in order to begin with a design that will support the entire product, including future enhancements, but simultaneously, to view that product as a sequence of builds each essentially independent of the next. Unless the developer is skilled enough to be able to handle this apparent contradiction, the incremental model may lead to an unsatisfactory product.

Spiral Model
------------

The idea of minimizing risks via the use of prototype and other means is the concept underlying the spiral model. Before commencing each phase an attempt is made to control (or resolve) the risks. Prototypes can be used effectively to provide information about certain classes of risk. Prototyping and risk management is performed during analysis, design and programming levels.

Analysis of Spiral Model
-------------------------

A major strength of the spiral model is that it is risk driven, but it can also be a weakness. Unless the software developers are skilled at pinpointing the possible risks accurately, there is a real danger that the team may believe that all is well at the time when the project, in fact, is headed for a disaster.
A second restriction to spiral model relates to the size of the project. Specifically the spiral model is applicable to only large scale software projects. It makes no sense to perform risk analysis if the cost of performing the risk analysis is comparable to the cost of the project as a whole or if performing the risk analysis would significantly affect the profit potential.

Component Based Development
---------------------------

Object oriented technologies provide the technical framework for a component based process model for software engineering. The object oriented paradigm emphasizes the creation of classes that encapsulate both data and the algorithms used to manipulate the data. If properly designed and implemented object oriented classes are reusable across different applications. The Unified software development process is the representative of a number of component based development models that have been proposed in the industry. Using the Unified Modelling Language(UML), the unified process defines the components that will be used to build the system and the interfaces that will connect the components.

Analysis of Component Based Development
---------------------------------------

The component based development leads to software reuse and reusability provides software engineers with a number of measurable benefits. The developers must have formal experience to apply UML tools such as Rational Rose, etc. For developers involved in several platforms, they may think Object concepts in a structured way. Since, being involved in structured approach they may conceptualize object oriented approach in a structured manner.

The RAD Model
--------------

An extremely short development cycle is the emphasis of the linear sequential software development process known as RAD (Rapid Application Development). RAD, which is driven by time, uses a component based construction approach that encompasses the following phases: business modeling, data modeling, process modeling, application generation, testing and turnover. Not all types of systems are appropriate for RAD development. Among these are systems that cannot be properly modularized and also systems with high technical risks. RAD requires customers who are committed to rapid-fire activities and is not appropriate when technical risks are high.

The Formal Methods Model :
--------------------------

Formal methods enable the software engineer to specify, develop, and verify a computer-based system through the application of rigorous mathematical notation. Formal methods provide a mechanism for eliminating problems such as ambiguity, incompleteness, and inconsistency. The formal method presents problems of its own, however, as it is viewed as time-consuming, expensive, difficult to use, and it requires extensive training.

Fourth Generation Techniques:
-----------------------------

Fourth generation techniques (4GT) represent a broad set of software tools that have one thing in common: "Each enables the software engineer to specify some characteristic of software at a high level." Then, based on the developer's specification, the tool generates the source code. 4GT provides a dramatic decrease in development time and improved productivity, but they are known to produce massive, inefficient blocks of code.

The following SDLC model is my newly developed model. It has already been published in an Indian IT magazine.( DeveloperIQ january 2003 issue, Asia's No:1 Software Technology Magazine)

Problem based Software Development (PBSD)
-----------------------------------------

Need for PBSD and advantages over existing models
-------------------------------------------------

Graphical aids may not describe how the final product will work. Also in order to develop the system using object oriented features a prototype would definitely be a analysis technique for the object oriented system. Our intention is Quality Software, for this I believe this method would be applicable for developing a Quality system using object oriented features. From the system requirements, the developer and designer (i.e designer and programmer) would sit and design a prototype and develop it. Here the importance is not given for strict structured or object oriented approach. The purpose of prototype is to know what the client really needs and establish the internal structure of system using object oriented features.
From the developed prototype extract the possible classes, member functions, data members. Identify access restrictions, overriding features i.e coupling and cohesion between classes and classes and its member functions. When the prototype is developed for the customer it can have GUI representations, fully developed front end. When the user feels to see the complete product the prototype is going to be for the analysis requirements of designer and programmer. In such cases we need the prototype, we don't need extensive GUI features.
This prototype would clear the characteristics, functions of the desired system. By this time we would be able to judge the time for developing the product. We set the time for completion of the project. The designer, programmer as well as SQA would be involved to produce specifications from prototype. PM(Total programmer effort in months), KDSI( Number of thousand's of delivered source instructions), depending upon the time taken to develop the prototype model it would be possible to predict the PM to be spent to develop the complete system.
During the next phase we develop the object oriented system. The prototype model implemented with objects will be presented in this step. From the object oriented specification bundled with data structures would produce the required code for the object oriented system. From the prototype we would extract the necessary components and conceptualize the system in object oriented paradigm. With the object identification and obtained code we can produce the required system. After the prototype and pertinent object construction the next job involves assessment of created system with a team of Program Analysts, experts, SQA group. Demonstration based assessment is one of the key factors for problem maturity. Here a review of the Object construction process is performed. Based on the feedback the constructed object model is refined in the next step. Since, in the prototype we have covered the required data structures for implementing the system. SQA will interact with the designer and programmer while developing the complete system. Now the product development is complete. By this time we must evaluate the estimated time for development. This process is a sign of Organization's CMM level implementation. The predicted Programmer months(PM) and KDSI and actual PM and KDSI would be compared to know the maturity and commitment of Employees.
The next phase is going to be Testing and delivery of the system. Since the system has object oriented features we need to introduce many testing techniques. Since our approach is quite clear, the risks would not be very high because we provide quality framework for software development. Testing is done to check for errors as well as establish performance of the system. Finally the system developed is delivered to the customer.

Phases of Developing System using PBSD
--------------------------------------

PHASE I

" Requirements Specification
" Prototype Construction
" PM, KDSI Estimation for modules


PHASE II

" Pertinent object construction
" Demonstration based assessment
" PM, KDSI evaluation


PHASE III

" Testing

Finally, the system developed in Object Oriented form is delivered.

Significance of Problem Based Software Development Model
--------------------------------------------------------

Prototype model gives relevant details of the object. Prototype plays a key
role to give knowledge about the system. OOSE is incorporated for object construction Abstraction, Inheritance, Polymorphism features are implemented for object construction. PM, KDSI evaluate the Quality of organization(PCMM) Early level demonstration based assessment is useful in attacking early risks Assessment's would provide the required feedback to modify the system. System developed is matured one. This model combines features on Component model, Prototype model, Waterfall model. The drawbacks and limitations of other model is overcome by this model


How this model makes Software development Accountable?

" Focus primarily on developing structure of system
" Our intention of prototype design yields Life-cycle benefit
" Develop performance criteria and evaluate

OPINIONS( Via e-mail)
---------------------

Roger S. Pressman, Ph.D.
R.S. Pressman & Associates, Inc.
6425 Via Rosa ** Boca Raton, Florida 33433 USA

(Author : Software Engineering a Practioner's Approach)

Although your efforts are commendable, the model that you propose is quite similar to many other models that have already been proposed in the literature. For example, Coad's Feature Driven Development (an agile method) has many of the same characteristics as
your model.

However, I would recommend that you spend some time investigating the latest agile methods (with their own process models) and see whether your
approach might be compatible.

Good luck with your studies and with your software process endeavors,

Best wishes,

Roger S. Pressman, Ph.D.
R.S. Pressman & Associates, Inc.
6425 Via Rosa ** Boca Raton, Florida 33433 USA

Sivaram,

I have read through the case study, impressive indeed. Couple of questions/concerns I have which are as under:

- Although prototyping is good as far as understanding systems'requirements and checking for completeness of the logical system, however, this is an overhead to the final product. The said model should define the scope of the prototype and the level of perception that this prototype will address. In other words, it should clearly identify what feature set from the requirement document(s) has to be implemented to make a valuable and functional prototype.

- The model may account for the unit and or integration testing time of the prototype in the overall project development time.

- [Lines: 19 - 21] What process would the model adopt to extract the classes, member functions etc.?

- [Lines: 26 - 28] The model must not limit the use of prototype to just understanding the system's characteristics and functions; rather it might be used for QA, such as understanding scalability, reliability, completeness and correctness.

Cheers

-Adnan Khan

My Replies
----------

Prototype Level
---------------

The expected level of prototype for a System depends on

How important the project is ?(milestone)
Time for development ?
Level of technology used ?
Product complexity ?

Class Extraction
----------------

The extraction of classes, member functions is a team work to be done by Requirements analysts, Designers, SQA team etc

Outline of model
----------------

The general layout of the model is presented. Based on the type of project we can add the above recommended features. The scope of prototype depends on the type of project discussed above

Regards,
Sivaram

I am looking forward to get recognition for the model

Waiting for future improvements,

Sivaram
aksivaram2k2rediffmail.com