What are the advantages and disadvantages of datagram approach?

- Today’s packet switching networks make use of a basic transfer unit commonly known as the datagram. 

- In such packet switched networks, the order of the data packets arrival, time of arrival and delivery comes with no guarantee. 

- The first packet switching network to use the datagrams was CYCLADES. 

- Datagrams are known by different names at different levels of the OSI model. 

- For example, at layer 1 we call it Chip, at layer 2 it is called Frame or cell, data packet at layer 3 and data segment at layer 4. 

- The major characteristic of a datagram is that it is independent i.e., it does not rely on any other thing for the information required for exchange.

- The duration of a connection between any two points is not fixed such as in telephone conversations. 

- Virtual circuits are just the opposite of the datagrams. 

- Thus, a datagram can be called as a self containing entity. 

- It consists of information sufficient for routing it from the source to the destination without depending up on the exchanges made earlier. 

- Often, a comparison is drawn between the mail delivery service and the datagram service. 

- The user’s work is to just provide the address of the destination. 

- But he/she is not guaranteed the delivery of the datagram and if the datagram is successfully delivered, no confirmation is sent to the user. 

- The data gram are routed to some destination without help of a predetermined path. 

- The order in which the data has to be sent or received is given no consideration. 

- It is because of this that the datagrams belonging to a single group might travel over different routes before they reach their common destination. 

Advantages of Datagram Approach

1. Datagrams can contain the full destination address rather than using some number.
2. There is no set up phase required for the datagram circuits. This means that no resources are consumed.
3. If it happens during a transmission that one router goes down, the datagrams that will suffer will include only those routers which would have been queued up in that specific router. The other datagrams will not suffer.
4. If any fault or loss occurs on a communication line, the datagrams circuits are capable of compensating for it.
5. Datagrams play an important role in the balancing of the traffic in the subnet. This is so because halfway the router can be changed.

Disadvantages of Datagram Approach

1. Since the datagrams consist of the full destination address, they generate more overhead and thus lead to wastage of the bandwidth. This in turn makes using datagram approach quite costly.
2. A complicated procedure has to be followed for datagram circuits for determining the destination of the packet.
3. In a subnet using the datagram approach, it is very difficult to keep congestion problems at bay.
4. The any-to-any communication is one of the key disadvantages of the datagram subnets. This means that if a system can communicate with any device, any of the devices can communicate with this system. This can lead to various security issues.
5. Datagram subnets are prone to losing or re - sequencing the data packets during the transition. This puts a great burden on the end systems for monitoring, recovering, and reordering the packets as they were originally.
6. Datagram subnets have less capability of dealing with congestion control as well as flow control. This happens because the direction of the incoming traffic is not specified. In the virtual circuit subnets, the flow of the packets is directed only along the virtual circuits thus making it comparatively easy for controlling it.
7. The unpredictable nature of the flow of the traffic makes it difficult to design the datagram networks. 

What is a structure point and what are its characteristics in domain engineering?

Structure points are one of the terms with which most of us are rarely familiar. But, the structure points indeed play an important role in the domain engineering.  Those who know something about the domain engineering, might be familiar with the term. This article is all about the structure points, their characteristics and what role have they got to play in the domain engineering. 

But, before moving on to the structure points, you need to know at least a little about the domain engineering.  

About Domain Engineering

Domain engineering consists of 3 primary phases namely:

1. Domain analysis
2. Domain design
3. Domain implementation

- Firstly, the application domain that is to be investigated is defined and all the common and varying points obtained from the domain are categorized. 

- These common and varying points are represented by the domain model. 

- The representative applications that are the result of the domain analysis are subjected to analyzation based on which the domain model is prepared which serves with the development of the architecture of the software system or application. 

- This process results in the formation of another model called the structural model. 

- This structural is said to consiss of a small number of structural elements in which you can clearly observe the interaction patterns manifesting. 

- The architectural that has been created in the previous steps can be re- used wherever required in the whole domain.

- The structural model is where the structure points come in to play! They act as distinct constructs within the structural model aspects like:

1. Interface
2. Response mechanism
3. Control mechanism etc.

The domain engineering promotes the re- use of the components of the existing software systems or applications. A repository of the re- usable components or artifacts is created.

Now moving on to the characteristics of the structure points, they have got three basic characteristics:

Characteristics of Structure Points

1. The structure points ought to implement the concept of information hiding by the means of isolating all the complexity of them. This has provided a great deal of help in the reduction of the overall perceived complex nature of the software system or application.

2. With the structure points, abstractions having a limited number of instances in the application re- occur in all the applications that lie within a domain. The size of the class hierarchy should be small for this characteristic to take effect. Plus if the abstraction does not occur in all the parts of the software application, you won’t be able to justify the cost to verify, document and disseminate the structure points.

3. The rules that govern the use of structure point are very easy to understand plus the interface of the structure point is relatively very simple.

What is Structural Modeling and what is the role of structure point?

- The structure modelling is an essential approach to the domain engineering and is facilitated by the structure points. 

- Structural modelling is actually a pattern based approach and works up on the assumption that every application domain consists of repeating patterns that can be effectively reused. 

- A structural model is composed of a number of structure points.

- These elements only characterize the architecture of the software systems or applications. 

- Simple patterns of interaction among these structure points can result in the formation of many architectural units. 

- Thus, structure point can be identified as a distinct construct within a structural model. 

Therefore the characterization of the structure points can be done as follows:

1. The number of instances of the structure point should be limited.
2. The interface should be relatively simple.
3. Information hiding must be implemented by the structure point by isolation all the complexity contained within the structure point. 

Explain Scrum - a type of an agile method?

Scrum as we all know is the agile software development methodology most in use nowadays for the development of many types of software systems and applications. It has been classified under the category of iterative and incremental development methodologies that works in an excellent way in managing the software products and projects. It also helps in management of the application development. 

Roles & Methods for Scrum Methodology

Some sets of predefined roles and methods have been defined for the scrum methodology:

1. The development team: It involves a team that is cross functional and self organized and takes care of the following processes:

          (a)    Analysis

(b)   Designing

(c)    Implementation

(d)   Testing and so on.  

At the end of each sprint, a shippable product is to be delivered by the development team. A typical development team may constitute of 3 – 9 members with self organizing skills which are required even though there is an interaction with the PMOs or project management organizations.

2. The product owner: The product owner is the representative of all the stake holders and sometimes may also represent the business. He/ she can also be regarded as the soul voice of the customer and he/ she is responsible for the following activities:

          (a)    Writing the customer centric items or user stories

(b)   Prioritizing the requirements based up on the user stories

(c)    Adding those identified requirements to the back log of the product.

This role is not supposed to be combined with the next one i.e., the scrum master.

3. The scrum master: The scrum master is responsible for ensuring that the whole process if followed and the impediments to the ability of the team are removed so as to make the delivery of the sprint goals easy and early. He is the one who facilitates the whole scrum development process. Scrum master as the name suggests should not be mistaken as the leader of the development team, he is in fact a buffer between the distracting influences and the development team. In a way he/ she make sure that the development process takes the intended route and enforces the rules to do so.

The above mentioned roles are called the core roles and there is another class of roles called the “ancillary roles” and as such they have no formal role but they have to be taken in to account. They have been mentioned below:

1. The stake holders and
2. The managers.

How Scrum is Useful?

- Scrum is quite useful when it comes to the management of the agile projects since it reinforces the interest in the agile development of the project. 

- The scrum and agile development method had come to challenge the conventional ideas regarding the agile project management. 

- Scrum methodology helps in the agile development at the steps where it becomes difficult to set the plan for upcoming processes. 

- The scrum and agile development methodology makes use of the concepts quite contrary to those used by the traditional development methods i.e., the mechanism of the empirical process control.

- Here the core management technique is constituted by the feedback loops. 

- The traditional development methods were command and control oriented.

- This mixed methodology of agile development and scrum has come to represent an entirely new radical approach that plans and manages the agile projects. 

- It has brought the level of the decision making authority to that of the operation certainties and properties.

- A project status meeting is held every day till the development continues which is called the “daily scrum”. 

- Below mentioned are some of the project management tools that support scrum:

1. Banana scrum
2. JIRA using Green Hopper plug-in
3. Mingle by thought works studios
4. Scrum Do
5. Pivotal tracker
6. Microsoft team foundation server

What is meant by evolutionary and adaptive development?

There are so many models designed for the development of the software systems or applications and a good tester needs to have knowledge of every software development model in order to decide for the best development model for building his/ her project. 

Types of Software Development Models

There are so many software development models available today like:

     1. Waterfall development model

     2. Spiral development model

     3. Iterative and incremental development model

     4. Agile development model

     5. Code and fix development model

     6. CMMI

     7. ISO 9000

     8. B – methods

     9. Petri nets

    10. Automated theorem proving

    11. RAISE

    12. VDM

    13. Z notation

    14. Chaos model

    15. Extreme programming

    16. ICONIX

    17. Incremental funding technology

    18. Software prototyping

    19. Rational unified process

    20. V model

    21. Service oriented modelling

    22. Evolutionary development model

    23. Adaptive development model

   

     This article has been written to discuss about the last two development models i.e., the evolutionary model and the adaptive model of software development. The water fall model is viable even today for the software products whose features do not change with time. 

     But what about the software applications whose features have to be redefined every now and then?? 

     The waterfall model does not hold to be appropriate. 

   

     

About Evolutionary Development Model

     - Under the evolutionary development model, the whole development cycle is broken down in to smaller waterfall models which can be incremented and the software product is accessible by the users when each cycle ends. 

     - Based on this product the users provide their feedback based on which the development plan for the next stage is created.

     - These incremental cycles can take up to 3 – 4 weeks and continue till the shipping of the software product. 

     - The business results as well as the internal and marketing operations are also benefited by the evolutionary development model if it is performed well. 

     - The best benefit of the business being a huge reduction in the associated risks like:

1. Missing scheduled deadlines
2. Wrong set of features
3. Poor quality
4. Unusable products and so on.

- Since the whole development process is broken down in to smaller ones, these risks become easily manageable. 

- Apart from this the evolutionary development helps in reducing the cost budget by the means of disciplined and structured avenue for doing the experimentation.

- The evolutionary development model has also been praised for the below mentioned matters:

1. Production of software systems and applications that fit the market requirements and needs of the users better.
2. Early deliveries in the marketing development.
3. Facilitation of the demonstration and the documentation.

With the constant feedback from the users in an evolutionary development model the team members are constantly motivated and encouraged. Now let us move to the other development model i.e., the adaptive development model that we had to discuss. 

About Adaptive Development Model

- In contrast to the evolutionary development model, the adaptive development model consists of shorter iterations, frequent releases of the working and useful softwares and continuous integration. - For an adaptive software development model the agile iterative approach is followed however no perspective set of rules has been defined. 

- Instead a couple of practices and principles have been identified.

- The adaptive development model has been inherited from the RAP or rapid application development. 

- This model is another attempt to replace the waterfall cycle with a development process that consists of speculative, collaborative and learning cycles.

- ASD is just the development process and is quite dynamic so as to provide adaptation to the state of project emergent in need. 

- Below mentioned are some of its characteristics:

1. Mission focused
2. Feature based
3. Iterative
4. Time boxed
5. Risk driven
6. Change tolerant

Explain Agile Model Driven Development (AMDD) lifecycle?

“AMDD” is the abbreviated form of the “agile model driven development” and nowadays is quite popular among the developers and programmers in the field of software engineering and technology.

AMDD took its birth from the “MDD” or the “model driven development” as its agile version that makes use of the agile models rather than using the extensive models in the pure model driven development. 

The agile model driven development was formulated out of model driven development since it was thought that the iterative development with the model driven development is possible. And since it constituted of the iterations, it was categorized under the category of agile software development methodologies. 

The agile models that drive the whole development procedure are good enough to take care of the development efforts. The agile model driven development is one of the most sought after beyond the small agile software scaling development methodologies.

Agile Model Driven Development Lifecycle

To understand this whole agile model driven development one needs to familiarize himself/ herself with the life cycle of this development model. This article is focused up on the life cycle of the agile model driven development only!

The life cycle of the agile model driven development is of quite a high level. So let us see what all are the various stages in the life cycle of the agile model driven development:

1. Envisioning: 

This stage of the life cycle is comprised of two more sub stages namely: the zeroth and the first iteration. These iterations usually come in to play during the first few weeks of the development process. This stage is actually included in to the life cycle with the purpose of the identification of the scope of the system and what kind of architecture will be suitable for developing the project. For this the following two sub stages come in to process:

(a)  Initial requirements envisioning or modeling: 

This stage may take up to several days for the identification of the high level requirements. Apart from just identifying the requirements the scope of the release product is also determined at this stage only. For carrying out with this stage the developer may require some type of usage model in order to see how the software project will be used by the customers or the users.

(b) Initial architecture modeling: 

This stage is all about setting up of a proper technical direction for the development of your software project.

      2. Iteration Modeling: 

     This stage involves planning for what is to be done with the current iteration. Often the modeling techniques are ignored by the developers while planning objectives for the iteration that is to be carried out next. The requirements in every agile model as we know are implemented in the order of their priority.

     

      3. Model Storming: 

      As mentioned in the agile manifesto the development team should consist of only a few members who are the ones who discuss the development issues by sketching it up on a white board or paper. The sessions which involve activities such as those are called the model storming sessions. These sessions are short enough to last for at most half an hour.

   

     4. Test driven development involving the executable specifications: this stage involves the coding phase using the re-factoring and test first design (TFD). The agile development helps you address cross entity issues whereas with the test driven development you can focus up on each and every single entity. Above all the technique of re-factoring the design, it is ensured that the high quality of the software project is not hampered at all.

Explain agile model-driven development (AMDD)?

AMDD stands for the agile model driven development which is not all to be confused with the agile model of software development. The model driven development or MDD is a separate development model and the AMDD i.e., the agile model driven development is its agile version. 

Not many of us familiar with this model. This article is dedicated to the agile model driven development model only. 

About Model Driven Development

- The model driven development involves the creation of the extensive software models before the actual coding is done.

- The best example for this is given by the Object Management Group (OMG’s) model driven architecture standard.

- Model driven development is quite famous with the developers who follow the traditional approaches whereas the agile model driven development has made it mark with the agile followers.

- After going through a research on the RUP/ EUP, it was observed that the model driven development can do with an iterative approach and thus the agile model driven development was born. 

- The basic difference here lies in the creation of the models.

- In the agile model driven development the agile models of the software are created rather than creating extensive models like in the case of the model driven development.

- These agile software models are good enough to drive the whole lot of the development efforts. 

- The agile model driven development is a methodology that has adopted for scaling of the agile software development. 

Activities included in life cycle of an agile project

Below mentioned are the activities that are included in the life cycle of an agile project:

1. Identification of the high level scope
2. Identification of the initial requirements stack
3. Identification of an architectural vision
4. Iteration modelling
5. Model storming
6. Test driven development (TDD)

Iteration activities In AMDD

The following are the iteration activities in an agile model driven development method:

1. Requirements envisioning
2. Architecture envisioning
3. Initial set up and planning
4. Investigative testing
5. Release
6. Production

- The envisioning is done usually in the first week of the development of a software project with the goal of identification of the scope of the software system or application and its architecture. 

- For this both the high level architecture modelling and the high level requirements modelling are required. 

- Envisioning is a means for exploring the requirements and develops a strategy for the development of your project. 

What is to be done in each iteration should be decided well before beginning with the iteration process?

- The agile software development principles insist that the requirements are implemented in the order of their priority levels.

- This is what is called as the iteration planning. 

- For the accurate estimation of the requirement it is required that you understand the work needed to be done for its implementation and this is where the modelling comes to help. 

- The model storming sessions are usually like some impromptu sessions which do not last for more than thirty minutes.

- It involves the discussion over an issue until all the members are satisfied with their understanding of the issue. 

- After this they again get back to coding process. 

- Model storming is often called as the JIT modelling or “just in time” modelling.

- During the whole development process several agile methodologies are followed like:

1. Test first design (TFD)
2. Refactoring etc.

- The above two agile methodologies combined together are known as the test driven development. 

- This is the stage in the agile model driven development where much of the time is spent. 

- Here the detailed modelling is carried out with the help of development tests, customer tests, executable specifications and so on. 

- The customers tests here are nothing but the agile acceptance tests. 

What are different Myths and Misconceptions surrounding Agile Model Driven Development (AMDD)?

The agile version of the model driven development or AMDD (agile model driven development) is now being recognized one of the most popular development models in the field of software engineering. This agile model driven development methodology was born out of a need of a combined development process of the agile methodology and the test driven development or TDD. 

The agile development in this combination is supposed to make the addressing of the cross entity issues easy while the TDD (test driven development) counterpart is suppose to focus exclusively on each and every individual entity of the software system or application. 

About Agile Model Driven Development

The agile model driven development lately has been known to suffer a lot of criticism giving way to the birth of several myths and misconceptions regarding it.

- The agile model driven development methodology has been characterized as an obsolete agile software development methodology to some extent though not so much. 

- The agile model driven development is thought to involve only a little bit of modeling but quite a lot of coding.

- The iterating efforts are deemed to be spread between the coding activities and the software modeling activities.

- Here a feel like illusion of majority of the designing being carried out as a part of the implementation efforts is created. 

- Such situations are also true for many other traditional software development methodologies. 

- In situations like this what happens is that the designers ultimately put the blame on the developers without questioning their own way of processing the software development.

- One of the misconception regarding the agile model driven development is that it does not specifies what all types of the software models are to be created.

- Even though it is always specified by the agile model driven development that only the right artifact is to be applied, it never does specify what that particular artifact really is. 

- One of the myths is that the agile model driven development works perfectly well with the UCDD (use case driven development) and the FDD (feature driven development). 

Myths and Misconceptions of Agile Model Driven Development

Below mentioned are some of the other myths and misconceptions surrounding the agile model driven development:

1. The agile models do not fulfill their purpose well.
2. It is very difficult to understand the agile models.
3. The agile models do not exhibit sufficient consistency.
4. The agile models are not sufficiently detailed.
5. The accuracy of the agile models is not so high.
6. The agile models exhibit a characteristic complexity.
7. Sometimes negative values are provided by the agile models.

Point of Argument

- Another most argued concept of agile model driven development is that the agile documents and models seem to be sufficient for carrying out the development.

- For this, the people develop false assumptions that the software is not as good as it portraits and expectations regarding the quality of the software artifact. 

- It is also thought that if the artifact has fulfilled the purpose which was intended then any more work that can be carried out on it is considered to be a useless bureaucracy. 

Benefits of Agile Model Driven Development

- The agile model driven development is known to take a more realistic approach and give a description of how the developers and stake holders are supposed to work together in cooperation to create good models.

- Agile model driven development is quite a flexible technology in the way that it allows the use most primitive and unsophisticated development tools for the creation of the models like papers and white boards as mentioned above.

- The agile model driven development is supposed to be independent of any sophisticated CASE tools even though they can be used effectively by the experts. 

Can Test Driven Development (TDD) work for data-oriented development?

Today the test driven development is quite a familiar concept among the developers and testers in the field of software engineering and technology and so is the data oriented development. 

Data oriented development is commonly known as the object oriented development. We have taken up an important question in this article which is “can test driven development work for data oriented development?”

But before answering this question we shall discuss about the two different developments involved in the question individually so that the understanding of the answer becomes easy. 

About Test Driven Development

First let us discuss about the test driven development. The test driven development as the term itself suggests is based up on carrying out the development process with the help of short development cycles that include the following steps:

1. Addition of a test: The development begins with the creation of test cases for all the features.
2. Execution of all tests in order to check the working of the new one.
3. Production of code implementing which the code can only pass the test and does not incorporates any new functionality.
4. Execution of the automated tests and observing their success.
5. Re-factoring or cleaning up of the code
6. Repetition of the whole cycle for the improvement of the functionalities.

Many development styles have been developed for the test driven development few of which are mentioned below:

1. YAGNI (you ain’t gonna need it),
2. KISS (keep it simple stupid),
3. Fake it till you make it and so on.

About Data Oriented Development

- It makes use of the models that are developed around the real world concepts.

- This development methodology involves the incorporation of the data behavior as well as the structure. 

- The process starts from the quantization of the data in to small distinguishable and discrete entities which are known as the “objects”. 

- Each of the objects created have their own inherent and unique identity. 

- Other characteristics of the data oriented development aare:

1. Classification
2. Inheritance
3. Polymorphism

- The essence of the object oriented development lies in the organization and identification of the application concepts.

- The primary focus lies with the analysis and design phases. 

- The data oriented development is known for encouraging the software developers to work and think. 

- This can be thought of as a conceptual process independent of a programming language. 

- The methodology here is to build the software model and add details to it during the design. 

- It consists of the following steps:

1. System conception
2. Analysis
3. System design
4. Class design and
5. Implementation

Can TDD work for Data Oriented Development

Now coming to our question, the answer is yes test driven development can absolutely work for the data oriented development since it has many characteristics and benefits that can be successfully incorporated in to the data oriented development:

1. Predictability: With the test driven development it is easy to predict that when the development process if finished since all the tests that they have are passed by the code.

2. Learning: With the test driven development the developers get a better understanding of the code and hence it becomes easier to develop the code that models the real world very well.

3. Reliability: Moreover the test driven development makes the data oriented development more reliable since it has a suite of regressions tests that cover all of the system aspects.

4. Speed: With the test driven development the data oriented development can be speeded up since a little time is spent debugging and mistakes are sought very soon.

5. Confidence

6. Cost

7. Scope limiting

8. Manageability

9. Documentation