Subscribe by Email


Showing posts with label Activity. Show all posts
Showing posts with label Activity. Show all posts

Friday, July 27, 2012

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.










Saturday, June 16, 2012

Code Restructuring - An activity involved in software re-engineering process model

As we know “Software re- engineering process model” is a model that has been used over the years to improvise the already existing poor code that is no longer accepted.  The poor code is restructured to meet the current standards of software engineering. This model consists of 6 basic steps as mentioned below:
  1. Inventory analysis
  2. Documentation reconstruction
  3. Reverse engineering
  4. Code re- structuring
  5. Data re- structuring
  6. Forward Engineering
This article is dedicated to the discussion regarding the fourth stage of the software re- engineering process model i.e., the code reconstruction. 



What is meant by Code Reconstruction?


- The code restructuring process involves analyzation of the source code. 
- The violations of the programming practices are noted down and later repaired. 
- The revised code is then reviewed and subjected to extensive testing. 
-Firstly, in this stage the program files that are executable are identified with the consultation of the person in the company who is intimate enough with the knowledge of the files and can grant some logic to their existence. 
- Next step, in this stage is the verification of the identified and setting up of the baseline. 
This step requires a lot of investigative work since the executable might have been affected by a lot of factors. 
- The code is verified using the sample input data or test files.
- The baseline for the executable is formed by documented data files and source code files. 
Now the developer who holds the responsibility to re- engineer the code, needs to familiarize himself with the existing code and figure how is going to re- engineer it. 
- He then carries out several walk-throughs and code reviews under many different conditions with its users.
- At this stage, the developer is free to introduce comments in to the code as per its re- structuring needs.
- Other requirements can be stated in the project log. 
- It is very common for the developer to encounter bugs at this stage. 
- The developer needs to discuss with the client and figure out a way of dealing with the bugs. 
- Next follows the identification of the requirements of the process like:
  1. Commenting the code.
  2. Modularity of the code.
  3. Documentation of the code.
  4. Enhancement of the code.
  5. Removal of the unused or unnecessary code.
  6. Removal of the duplicate code.
  7. Removal of duplicate parameters.
  8. Porting of the code to another platform.
  9. Enhancement of the user interface.
  10. Defining the language standard of the code.
  11. Conversion of the code in to an alternative development language.
  12. Improvement and maintenance of the performance.
  13. Optimization of the code.
  14. Improvising the internal error handling capacity of the code.
  15. Inclusion of additional functionality.
  16. Fixing the existing bugs.
  17. Implementing alternate third party products.

More about Code Restructuring


- The code is restructured in identifiable phases i.e., the original code is re- engineered in the phases that have been identified. 
- The software tools here may be helpful in the investigation of the code coverage, unused variables, hot spots, coding standards and so on. 
- Apart from these, manual inspections can also help a big deal in identification and removal of the duplicated and false code, collate parameter definitions and optimize the array storage. 
- On an overall basis, restructuring of the code greatly improves its performance. 
- Even the simplest of the “not so obvious” issue can significantly affect the performance of the code like accessing of the data. 
- Different languages have their own way of storing arrays. 
- Therefore, the way that is used to access this data can hamper the performance to a great extent without coming to the knowledge of the developer. 
- Lastly, the code is tested after the completion of the restructuring. 


Reverse Engineering - an activity involved in software re-engineering process model.


Software re-engineering process model is a very generic process meant to uplift the standard of the poor code that is currently not acceptable. This model is known to have 6 major stages namely:
  1. Inventory analysis
  2. Documentation reconstruction
  3. Reverse engineering
  4. Code re- structuring
  5. Data re- structuring
  6. Forward Engineering
This article is all about the third stage i.e., “reverse engineering” which is an important concept in itself. 
Re- engineering is usually required when the some of the sub systems of a larger software system or application need to frequently maintained. The re- engineered system is then restructured and re- documented. 

What is Reverse Engineering?


- The reverse engineering forms a very important factor in success of the re- engineering process. 
- The reverse engineering can be considered to be a process of recovering the design of the software system or application that is to be re- engineered. 
- This step involves analyzation of the software program in an effort to obtain an abstract level representation of the program that is higher than the level of the source code.  
- The software system or application is analyzed in such a way so as to understand its design and specifications and requirements. 
- Reverse engineering is an entirely individual process.
- In some cases the reverse re- engineering may be used  for specifying a software system before it is implemented again. 
- The reverse engineering process makes use of the program understanding tools like:
  1. Browsers
  2. Cross reference generators and so on.

Levels in Reverse Engineering


The reverse engineering process takes effect through the following levels:

1. Abstraction level: The design information of the software system or application is derived at the highest level possible.

2. Completeness: At the above abstraction level, the details of the system are obtained.

3. Interactivity: The degree of the human integration with 5the automated reverse engineering tools is measured.

4. Directionality: It can be either:
(a)  One way: All the extracted information is given to the sogftware engineering who is doing the maintenance.
(b)  Or two way: All the extracted information is fed to a re- engineering tool which then regenerates the old software program.

      5. Extract abstraction: From the old source the processing specifications are obtained.

     

Stages in Reverse Engineering Process


      Reverse engineering process from sommerville goes through the following stages:
      1. System to be re- engineered is subjected to automated analysis.
      2. Then it is manually annotated.
      3. With the system information obtained, a whole set of new documentation is generated containing:
       (a)  Program structure diagrams 
       (b)  Data structure diagrams and 
       (c)   Trace ability matrices.

     

Activities in Reverse Engineering Process


     There are 3 basic activities involved with the reverse engineering process:
   
    1. Understanding process: In order to understand the procedural abstractions as well as functionality analyze the source code on the level:
      (a)  System
      (b)  Program 
      (c)   Component 
      (d)  Statement and 
      (e)  Pattern
    
       2. Understanding data:  It analyzes internal data structures and data base structure.  
   3. User interfaces: It analyzes the basic actions processed by the interface, system’s behavioral response to those actions and equivalency of the interfaces.

When is Reverse Engineering Preferred?


- Reverse engineering is usually preferred when the specifications and designs of the system are required to carry out the program maintenance activities.
- The re- engineering process is preceded by the reverse engineering. 
- To put it simply, the reverse engineering can be thought of as a process that goes back through the whole development cycle.
- UML is a source that supports reverse engineering. 
- Different people have their own different perceptions of the reversion engineering. 
- It can also be thought of as an inversion of the water fall model of software development. 


Thursday, August 25, 2011

What is a process framework? What is the approach of a successful project?

The process framework establishes a skeleton for project planning. It is adopted by allocating a task set that is appropriate to the project. There should be some flexibility given to the software team to select the best process model and engineering tasks suitable for the project.
- For a small project, linear sequential approach can be used.
- If for a project, tight time constraints are applied, RAD model can be used.
- If for a project, deadline is very tight, an incremental approach can be used.

After the selection of the appropriate process model, process framework is adapted to it. The process framework is invariant in nature and it acts as a basis for all software work.Process decomposition starts when the project manager wants to know how can this framework activity be accomplished.

Approach to manage a successful software project are:
- One should start on the right foot.
- Momentum should be maintained.
- Progress should be tracked.
- Decisions should be made smartly.
- Postmortem analysis should be conducted.


Friday, February 25, 2011

How to design conventional components - Graphical Design Notation and Tabular Design Notation

There were some logical constructs developed from which any program could be formed. Each construct has a logical structure. The constructs are sequence, condition, and repetition.
- Sequence implements processing the steps that are essential in the specification of any algorithm.
- Condition provides the facility for selected processing based on some logical occurrence.
- Repetition allows for looping.
Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition and repetition. The structured constructs were supposed to limit the procedural design of software to a small number of predictable operations.

GRAPHICAL DESIGN NOTATION
Activity diagram allows a designer to represent sequence,condition and repetition. Flowchart, like an activity diagram, is quite simple pictorially.
The dogmatic use of only structured constructs can introduce inefficiency when an escape from a set of nested loops or nested conditions is required. Additional complication of all logical tests along the path of escape can hinder the control flow, increase the possibility of error and have a negative impact.
There are two options:
- procedural representation is redesigned so that escape branch is not required at a nested location.
- structured constructs are violated in a controlled manner; that is , a constrained branch out of the nested flow is redesigned.

TABULAR DESIGN NOTATION
Decision tables translates actions and conditions in a tabular form. It is difficult to misinterpret. A decision table is divided into quadrants:
- Upper left quadrant: contains a list of all conditions.
- Lower left quadrant: contains a list of all actions that are possible based on combinations of conditions.
- Right hand quadrant: a matrix that indicates condition combinations and corresponding actions. Each column of matrix may be interpreted as a processing rule.

-


Friday, January 21, 2011

The WebApp Design - Attributes, Goals and Web Design Pyramid

Design is an engineering activity that leads to a high quality product. The major attributes of quality for web applications are:
- Security : The main emphasis of security is the ability of the web application and its environment to avoid unauthorized access or attack.
- Availability : Web application will not meet users needs if its unavailable. Availability is the measure of the percentage of time that a web application is available for use.
- Scalability : Is the variation in volume handled significantly by the web applications and the system. It is important to build a web application that can accommodate the burden of success.
- Time to market : It is a measure of quality from business point of view.

What should be considered when assessing content quality?
- Scope and depth of content be easily determined so that it meets user's needs?
- Background and authority of content's author be easily identified?
- Possibility of determining the currency of content, last update?
- Stability of content and location?
- Credibility of content?
- Uniqueness of content?
- Is content well organized?
- Is content valuable?

Design Goals


The design goals for every web application are:
- Simplicity
- Consistency
- Identity
- Robustness
- Navigability
- Visual appeal
- Compatibility

Web Design Pyramid


Each level of the pyramid represents the design activities:
- Interface Design : It describes structure and organization of the user interface. It includes screen layout, interaction modes, navigation mechanisms.
- Aesthetic Design : It describes the look and feel of the application.
- Content Design : It defines layout, structure and outline of all content.
- Navigation Design : It describes the navigational flow for web application.
- Architectural Design : It represents the overall hypermedia structure.
- Component Design : It develops detailed processing logic.


Monday, January 3, 2011

How to execute Performance Tests?

Performance testing involves executing the same test case multiple times with data variations for each execution, and then collating response times and computing response time statistics to compare against the formal expectations. Often, performance is different when the data used in the test case is different, as different number of rows are processed in the database, different processing and validation come into play, and so on. By executing a test case many times with different data, a statistical measure of response time can be computed that can be directly compared against a formal stated expectation.

Network sensitivity tests are variations on load tests and performance tests that focus on the Wide Area Network (WAN) limitations and network activity. Network sensitivity tests can be used to predict the impact of a given WAN segment or traffic profile on various applications that are bandwidth dependent. Network issues often arise at low levels of concurrency over low bandwidth WAN segments. Very chatty applications can appear to be more prone to response time degradation under certain conditions than other applications that actually use more bandwidth. For example, some applications may degrade to unacceptable levels of response time when a certain pattern of network traffic uses 50% of available bandwidth, while other applications are virtually un-changed in response time even with 85% of available bandwidth consumed elsewhere.

This is particularly important test for deployment of a time critical application over a WAN. Also, some front end systems such as web servers, need to work much harder with dirty communications compared with clean communications encountered on a high speed LAN in an isolated load and performance testing environment.


Monday, December 20, 2010

How does stress test execute?

A stress test starts with a load test, and then additional activity is gradually increased until something breaks. An alternative type of stress test is a load test with sudden bursts of additional activity. The sudden bursts of activity generate substantial activity as sessions and connections are established, where as a gradual ramp-up in activity pushes various values past fixed system limitations.
Ideally, stress tests should incorporate two runs, one with burst type activity and the other with gradual ramp-up to ensure that the system under test will not fail catastrophically under excessive load. System reliability under severe load should not be negotiable and stress testing will identify reliability issues that arise under severe levels of load.
An alternative, or supplemental stress test is commonly referred to as a spike test, where a single short burst of concurrent activity is applied to a system. Such tests are typical of simulating extreme activity where a count down situation exists. For example, a system that will not take orders for a new product until a particular date and time. If demand is very strong, then many users will be poised to use the system the moment the count down ends, creating a spike of concurrent requests and load.


Saturday, December 18, 2010

Overview of Stress Testing and its Focus..

Stress Tests determine the load under which a system fails, and how it fails. This is in contrast to load testing, which attempts to simulate anticipated load. It is important to know in advance if a stress situation will result in catastrophic system failure, or if everything just goes really slow. There are various varieties of stress tests, including spike, stepped and gradual ramp-up tests. Catastrophic failures require restarting various infrastructure and contribute to downtime, a stress-full environment to support staff and managers, as well as possible financial losses. If a major performance bottleneck is reached, then the system performance will usually degrade to a point that is unsatisfactory, but performance should return to normal when the excessive load is removed.
Before conducting a stress test, it is usually advisable to conduct targeted infrastructure tests on each of the key components in the system. A variation on targeted infrastructure tests would be to execute each one as a mini stress test.

What is the focus of stress tests?


In a stress event, it is most likely that many more connections will be requested per minute than under normal levels of expected peak activity. In many stress situations, the actions of each connected user will not be typical of actions observed under normal operating conditions. This is partly due to the slow response and partly due to the root cause of the stress event.

If we take an example of a large holiday resort web site, normal activity will be characterized by browsing, room searches and bookings. If a national online news service posted a sensational article about the resort and included a URL in the article, then the site may be subjected to a huge number of hits, but most of the visits would probably be a quick browse. It is unlikely that many of the additional visitors would search for rooms and it would be even less likely that they would make bookings. However, if instead of a news article, a national newspaper advertisement erroneously understand the price of accommodation, then there may well be an influx of visitors who cl amour to book a room, only to find that the price did not match their expectations.

In both of the above situations, the normal traffic would be increased with traffic of a different usage profile. So, a stress test design would incorporate a load test as well as additional virtual users running a special series of stress navigations and transactions.
For the sake of simplicity, one can just increase the number of users using the business processes and functions coded in the load test. However, one must then keep in mind that a system failure with that type of activity may be different to the type of failure that may occur if a special series of stress navigations were utilized for stress testing.


Facebook activity