What are the causes for the failure of traditional planning approach?

The traditional planning approaches does not always lead to very satisfactory results.

Causes for Planning Failure

Cause #1: Planning is done by activity and not feature
- The traditional approaches to planning focus on activity completion rather than on delivery of features.
- Activity based plans generally lead to projects that overrun their schedules.
- Hence, quality is reduced.

Cause #2: Activities do not finish early
Cause #3: Lateness is passed down the schedule
- Traditional approaches being activity based, their main focus is to focus on dependencies between activities.
- Testing will start late if anything goes worse than planned according to traditional approach.
- Testing will start early if everything goes better than planned.

Ways to avoid late start of testing are:
1. User interface coding finishes late.
2. Middle tier coding takes longer than planned and finishes late.
3. Middle tier coding starts late as tables adding to database finishes late.
4. Tester is not available.

Cause #4: Activities are not independent
- Activities are independent if duration of one activity does not influence the duration of another activity.
- For independent activities, late finish on one activity can be offset by an early finish on another.


Cause #5: Delay caused by multitasking
- Multitasking exacts a horrible toll on productivity.
- It becomes an issue once a project starts to have some activities that finish late.
- Dependencies between activities become critical.
- For a traditionally planned project, multitasking becomes a problem for two reasons:
1. Work is assigned in advance and it is impossible to allocate work efficiently in advance.
2. It focuses on achieving high level of utilization of all individuals rather than on maintaining sufficient slack.

Cause #6: Features are not developed by priority
Cause #7: Ignoring Uncertainty
- We fail to acknowledge uncertainty in traditional approach.
- Ignore the uncertainty about product.
- Assuming initial requirement analysis will lead to complete specification of product.
- Ignoring uncertainty about how we will build the product.
- The best way to deal with uncertainty is to iterate.


After looking at the problems with traditional approaches to planning, many projects are disappointing. Planning based on activity diverts us from features and as a result, a variety of problems leads to the likelihood of delivering late against a schedule.

What is meant by the term system metaphor? What is its use?

System metaphor- well this is a term which is related to the extreme programming but less known of! What is the system metaphor and what is its use and what is the need? 

We shall be discussing all these aspects of the system metaphor in this article. 

"A system metaphor in the simplest words can be defined as a story that any one includes customers, programmers and managers) can tell reading how a system works".

Reasons why we need to use System Metaphor

There are several reasons for why we need to use the system metaphor.  They have been listed below:

1. Architecture: The metaphor is consider to shape the software system or application exactly as it is required by us with the help of identifying the key objects and giving suggestions regarding the aspects of their interfaces. The dynamic and the static models of the system are supported by the system.
2. Shared Vocabulary: A common system of names for the objects and relationships that exist between them are suggested by a system metaphor only and thus it provides a powerful vocabulary for the developers and programming experts. The vocabulary created is shorthand and specialized.
3. Common Vision: System metaphor comes in to as a very handy tool that helps in enabling all the stake holders to agree up on the working of the software system or application. The key structure of how the problem and the solution have been perceived is provided by the system metaphor itself. Overall, this helps in understanding the working of the system well.
4. Generativity: A system metaphor by the means of its analogies can get you new ideas regarding the problem and its solution and can further dig out many other important issues.

How to choose a System Metaphor?

- Even though choosing up a proper system metaphor for your system may take some time and efforts, it is the best option that you have for exploring several possibilities just by looking at the system through various views. 

- If by combining two metaphors you are getting the one that is fit for your then go for it. 

- Now what if you come to know that you could have got a better metaphor for your system than what you have already opted for? No need to worry, you can still develop your system in that direction. 

- Such a measure will also help you in achieving a greater understanding of your problems. 

- What if you are not able to think of any good metaphors? 

- There are some naive metaphors always available to your rescue. Below mentioned are some examples of the system metaphors:

1. Use of a pension tool as a spreadsheet.
2. Using desktop metaphor for graphical user interface.
3. Buckets, lines and bins in C3 payroll.
4. Bills of materials in VCAPS.
5. A double entry system being used as book keeping and spreadsheet.

More about System Metaphor

- Suppose you sign a contract with a client for developing some software system, what you do next? 

- You search for a good system metaphor that will guide the development of your software system or application.

- A metaphor very well guides the development process of a project. 

- Not any one can choose a good metaphor, it requires skills, practice and of course deep knowledge.

- A system metaphor is nothing but a metaphor having a simple design and some essential qualities that the original needs to have. 

How does penetration testing tool emphasize on network security?

The term “penetration testing” is not unheard these days and perhaps many of us are familiar with this type of testing. In this piece of writing we have discussed how the penetration testing tools emphasize up on the network security. 

About Penetration Testing

- Penetration testing is yet another testing methodology that has been adopted for testing the security of a computer network or system against the malicious attacks. 

- It provides a way to evaluate the security level of the computer network by bombarding the network with false simulated attacks as malicious attacks from the outside as well as inside attackers. 

- The aliens, foreigners or outside attackers do not hold any authorized access to the computer system or network but the inside attackers do have that access, but it is limited to a certain level.

- The whole process of the penetration testing is dependent on an active analysis. 

- This active analysis carries out an assessment of all the potential vulnerabilities of the computer network or system that are merely a consequence of its poor security level as well as configuration level. 

- Apart from this, the known and unknown flaws form both the hardware as well as software system contribute to these vulnerabilities rather than only operational weaknesses. 

- Therefore they are to be blamed equally.

- This active analysis is successful only if it is carried out from the view point of a malicious attacker and is concerned about the active exploitation of the recognized vulnerabilities.

About Network Security

- The network security depends up on the effectiveness of the testing. 

- And the testing in turn is affected by the effectiveness of the tools that are employed in the testing.

- The tools indeed affect the network security, since if the tools are reliable and efficient in finding vulnerabilities, obviously there will be more improvement in the security mechanisms.

Reasons why Penetration Testing holds good for Network Security

There are several other reasons why the penetration testing tools holds good for the network security:

- They are effective for the determination of the feasibility of the similar vectors of attack.

-  Help in the identification of the vulnerabilities which possess a very high risk when the exploitation of a combination of low level risks is done following a particular sequence.

-  Prove quite effective in the determination of the vulnerabilities that cannot be detected with the help of application vulnerability scanning software or automated testing processes.

-  Assist in the assessment of the measure of the operational and business impacts of the attacks on the computer network or system.

- Successfully test the effectiveness of the network defenders in detecting and responding to the attacks.

- Provide the evidence in support of the investments that need to be made in the security field of the computer system or network.

What is a mock object? What are the reasons for use?

Perhaps most of us have heard about mock objects but do not know what it is actually! This article is dedicated to the mock objects and the reasons for which they are used.

First we will clear up the concept of mock object and then we will move on to the reasons for its use. Mock objects are a concept of the object oriented programming.

" Mock objects are defined as some simulated objects that have the ability to mimic the behavior of the real objects in a defined and controlled way. Mock objects are used by a programmer or developer to check another object by testing it against the mock object."

Reasons for use of mock objects

- Mock objects as we discussed above are able to perfectly simulate the behaviour of real or we can say non- mock object be it very simple or very complex.

- This property of the mock objects make them an essential and convenient tool for carrying out an effective unit testing which involves testing of the software program modules in isolation.

- It should not be mistaken that the mock objects are used in the place of the original non mock objects.

- They are used in their place only during the testing phase and that too when it is almost impossible and impractical to incorporate the real object in to the created unit tests.

- In some of the cases it is required the presence of some object for testing another one. In such cases the mock objects play a very important role.

Characteristics of Mock Object

Below mentioned are some characteristics which if are present in a non mock object, it is important that you use a mock object in its place:

1. If the object supplies non deterministic results such as the current temperature and current time etc.

2. If the object is having states that are somewhat difficult to be reproduced and recreated such as a network error and so on.

3. If the object is too slow i.e., if it is having a complete data base which requires initializing before the starting of the test.

4. If the object does not exist in practical.

5. If the object tends to change its behavior.

6. If the object currently does not exists.

7. If the object requires including the methods and information regarding the testing purposes but not its actual tasks.

8. If the object is difficult to set up.

9. If the object is a user interface.

10. If the object cannot be queried.

We will give an example so that the mock object concept becomes clear to you!

- Consider your mobile alarm clock which causes an alarm bell to ring at the time that you specify.
- Suppose it gets the current time from somewhere outside, then how do you test this mobile alarm?
- You will have to wait till the alarm bell goes off till that specified time to check whether or not the mobile alarm is working correctly or not.
- Mock objects are sometimes used as mediators.
- In such cases a mock domain comes in to play rather than the actual domain.

Features of Mock Object

Below mentioned are some of the features of a mock object:
- Easy to create
- Easy to set up
- It is quick
- Deterministic
- Easy to cause behavior
- Does not have any direct user interface
- Can be queried directly

The mock objects did not come in to existence in a single day. It took a whole lot of days to experiment, discuss and collaborate and put forward the idea of using a mock object.

Overview of Aspect Oriented Software Development (AOSD)

Aspect oriented software development defines aspects that express customer concerns that cut across multiple system functions, features, and information. It provides a process and methodological approach for defining, specifying, designing, and constructing aspects - mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concern.
Aspect Oriented Programming (AOP) provides the ability to intercept code execution with the purpose of inserting a process before, in place of, or after the code that would normally execute.

Predominant reasons for AOSD are:
- Help solve the issue of messy object architectures.
- Object oriented programming has difficulty dealing with global information.
- Also, functionality that requires the involvement of several different objects (possibly collected into a component) results in interdependency between those objects/components. This makes the application susceptible to the implementation changes of a dependent object/component.
- Maintenance and enhancement are also problems, as the interaction between these objects/components are typically hard coded within the containing object.

AOSD programming technologies (aspect-oriented programming, or AOP) provide linguistic mechanisms for separate expression of concerns, along with implementation technologies for weaving these separate concerns into working systems. Aspect-oriented software engineering (AOSE) technologies are emerging for managing the process of developing systems within this new paradigm.

Overview of Reverse Engineering

Reverse engineering is the attempt to recapture the top level specification by analyzing the product - I call it an "attempt", because it is not possible in practice, or even in theory, to recover everything in the original specification purely by studying the product.

Reverse engineering is difficult and time consuming, but it is getting easier all the time thanks to IT, for two reasons:
- Firstly, as engineering techniques themselves become more computerised, more of the design is due to the computer. Thus, recognisable blocks of code, or groups of circuit elements on a substrate, often occur in many different designs produced by the same computer program. These are easier to recognise and interpret than a customised product would be.
- Secondly, artificial intelligence techniques for pattern recognition, and for parsing and interpretation, have advanced to the point where these and other structures within a product can be recognized automatically.

Reverse engineering generally consists of the following stages:
1. Analysis of the product
2. Generation of an intermediate level product description
3. Human analysis of the product description to produce a specification
4. Generation of a new product using the specification.
There is thus a chain of events between the underlying design specification and any intermediate level design documents lying behind the product, through the product itself, through the reverse engineered product description, through the reverse engineered specification, and into the new product itself.

Reasons for reverse engineering:

- Interoperability.
- Lost documentation: Reverse engineering often is done because the documentation of a particular device has been lost (or was never written), and the person who built it is no longer available. Integrated circuits often seem to have been designed on obsolete, proprietary systems, which means that the only way to incorporate the functionality into new technology is to reverse-engineer the existing chip and then re-design it.
- Product analysis : To examine how a product works, what components it consists of, estimate costs, and identify potential patent infringement.
- Digital update/correction : To update the digital version (e.g. CAD model) of an object to match an "as-built" condition.
- Security auditing.
- Military or commercial espionage : Learning about an enemy's or competitor's latest research by stealing or capturing a prototype and dismantling it.
- Removal of copy protection, circumvention of access restrictions.
- Creation of unlicensed/unapproved duplicates.
- Academic/learning purposes.
- Curiosity.
- Competitive technical intelligence.
- Learning.