Software Engineering Blog | Software engineering , Software Document ,Software Process

How the Scrum Strategy of Software Development Works

2012-01-29T21:05:00.000-08:00

What is scrum? It's a special approach to software development. Instead of a full process, people who use this process work within a framework. So there is a much less formal approach to things in the sense that a very specific plan is excluded in favor of leaving things up to the software development team. And the reason why this is done is because the team will have a better idea of what sort of options are best used for solving a particular type of problem.

This sort of process is in contrast to sprint planning, which is a type of approach that is based around the goal of reaching a specific desired outcome. Instead, the scrum system works through a self-organizing, cross-functional team, which means that the goal is greatly influenced by the team and not necessarily by any specific goal. It also involves putting together feasible ideas and then implementing them. To carry out this process, the entire team will need to assign two positions: a ScrumMaster and a product owner. Although the approach tends to be somewhat less rigid, it still requires a certain level of control and organization.

The ScrumMaster's purpose is to act as a coach, essentially helping each member of the team figure out how they can best contribute to the framework. On the other hand, the product owner represents the target consumer and basically guides the team into creating a product which fits well with the demands of the business as well as its target consumers.

Also, scrum projects do not define progress in terms of a straight line but instead as a series of sprints which are timeboxed iterations for a given period of time, typically a month or a few weeks. At the start of each period, team members will divide the tasks among themselves. The goal is to deliver a particular number of features within a given period of time. Once they have carried out the necessary tasks, the features submitted by each member of the team will then be coded and tested. After that, the team members will then coordinate on how to best integrate these various features onto the system.

After the initial tests and evaluations, the new features are then reviewed by the team, the ScrumMaster and product owner. This is done at the end of the scrum process, and it also includes demonstrations of what the new features can do for the product owner or any other person who is interested in the project.

The Evolution and Concept of Open Source Development

2012-01-12T19:47:00.000-08:00

The Evolution and Concept of Open Source Development

Open Source (Free) development is a methodology of creating software products from the design, development to its distribution. Developers often distributed such free software under the GPL (General Public License). This methodology provides a source code access to anybody and everybody aspiring to develop the software further for the good.

The evolution of Open source development

During the period of 50's and 60's, software were distributed free of cost to enhance the functionality of the hardware or to promote the hardware. People involved in the computer business dealt with hardware and freely distributed codes to encourage hardware sales. Also, buyers often had to change the code to make it work according to their business. They also had to fix bugs or add new features supporting hardware issues.

During early 1970's, operating system and compilers began to grow rapidly. This development phase led to the surge in software demand, which had software companies to begin charging for the software licenses. Software started selling with several legal restrictions including copyright, trademark and leasing contracts.

The Open Source trend evolved during 1984 and 1985 when Stallman started the GNU project with an ultimate goal of getting the operating system developed and edited by genius developers without the expensive licensing issue and source code restrictions. This promoted Open Source development not only for operating system, but also for other areas of computing. Later, GNU General Public License became a legal tool ensuring that software under the GNU will remain free.

Open source framework programming advanced and today major companies accept its integration. This system developed some of the most famous and robust software namely Mozilla Corporation products, Firefox; Linux and UNIX operating systems; LAMP software stack and so on.

The Concept

Although we fondly call these applications as free software, the term "free" refers to its nature, meaning users have liberty to study, use and modify the software. In terms of price, these applications are not available free of cost, but one can easily avail them at minimal charges. This type of application development is, generally, an initiative from the non-profit organizations.

The customization of such software makes proprietary software owners uncomfortable due to its lower cost of development, support and license. Also, there is a wide scope for open source development and integration, as the huge communities and developers with better skills back the technology. These solutions are faster and scalable as compared to their proprietary counterparts. Moreover, these solutions offer more stability as they can be freely changed with time and according to the usability.

Is open source integration preferable?

Today, most companies feel implementing free software framework programming techniques are safer and hassle-free, as companies don't have to go through the complicated proprietary software licensing process. Free applications are community driven and community serving; brilliant programmers across the world join these communities and put their efforts to serve it better.

Open source is self-sustained. It doesn't belong to a specific organization, but to the community. Therefore, Open Source integration is always preferable as if a company initiating a specific development goes bankrupt, the software still remains strong, and the development never stops, as it is well-maintained by the community.

What is Scrum , Anyway ?

2012-01-10T21:53:00.000-08:00

What is Scrum , Anyway ?

If you're a budding software developer, you've probably heard of the term "scrum" being passed around. Moreover, you've probably wondered what this strange-sounding word means, and why it seems to hold such importance. Despite how foreign or alien it sounds, though, the term can actually be very easily understood. It is quite a simple method, but a powerful one at the same time.

The word represents a revolutionary method of software development. What makes it different from other methodologies, however, is that it is not as strict and detailed when it comes to the process. It doesn't have a definitive set of rules that everyone involved has to follow religiously. When it comes to scrum, the basics of the process vary from one development team to the next. One software developer can use the framework in a quite different way from another software developer, but both will still adhere to the framework's basic principles.

Through this method, the entire process is split up into small sections called "sprints." More often than not, these sprints last between two to four weeks long - a relatively short time, if you think about it. So why the short time period? This is because the process works best for projects where requirements can change at any given moment. When you use the scrum methodology, sudden changes can be handled quite easily. Since the process is performed in iterations, it's far easier to incorporate a new requirement or change in requirements without the need for inconvenient overhauls. Software development, for instance, always requires the people involved to be on their toes. With this revolutionary new method, these people don't have to be as tense or anxious.

Embracing this framework will definitely make meetings with your development team much easier and more effective. Instead of having to go through the standard ETVX discussion, which determines Entry Criteria, Task Definitions, Validation Criteria, and Exit Criteria, people using scrum simply have to focus on the tasks and goals for the upcoming sprint - no more, no less. This makes things far more dynamic, and keeps people focused on the most important aspect of the project at any given time.

Gone are the days when managing a project meant laying everything out from the very beginning and just hoping against hope that absolutely nothing goes wrong along the way. With this great new method, a team is very well-equipped for any emergency. It was designed to withstand even the most extreme changes in requirements. This proves that it never really pays to be stubborn and stay stuck in your ways. Life is truly unpredictable, and any team worth their salt should embrace this truth with open arms.

If you and your team are still doing things the old-fashioned way, you should really give this new method a shot. It is guaranteed to make things run far more smoothly than you've ever imagined. What's the point of sticking to traditions, after all, when there's something new and considerably better just waiting around the corner?

Software Quality Assurance: Why Do You Require It?

2011-12-11T17:33:00.001-08:00

Software Quality Assurance: Why Do You Require It?

With the fierce competition in the business sphere, it's paramount to have strategic advantage. However, the task apparently seems to be big challenge since an enterprise often grapples with countless core & non-core business objectives. It has been observed that in order to meet the product release date, often testing time is considerably reduced; this greatly hampers the quality of the product. To ensure good-quality product release, most companies today prefer to outsource their software testing assignments offshore.

Software Quality Assurance is indeed a positive way to accomplish the ultimate goal of customer satisfaction. Every due care must be taken to locate the bugs in the product and fix the same. Sometimes, a bug is located beneath several functional layers of the product and its effect is minimal on the performance of the product. However, there are certain bugs, which are present on the surface and have major effects such as the ones leading to crashing of data, and eventually bigger losses. Thus, testing needs to be done right from the beginning of software development life cycle to ensure bug-free software release.

Quality Assurance Testing is conducted not only to locate bugs, but also for a variety of other objectives too like performance, confirmatory tests etc. Hence, an apt strategy needs to be devised before attempting Quality Assurance Testing lest it would lead to few or more missed bugs. Hence, answer to the questions "Why we're testing?" and "What we are going to test?" must be with you before you actually get started with the testing process.

Once you're done with figuring out the answers to the two most important questions listed above, you can begin the series of activities to assess the quality and performance of the software product. Both manual and automating testing can be carried out to spot the bugs. After every test run, the located bugs can be sent to the development team for rectifications. Once a batch of located errors gets resolved, the testing team repeats the test runs to validate that those bugs exist no more. Next comes the turn of new errors being pointed out, and the cycle continues until the product quality reaches optimum levels.

Defining Scrum: A Compilation of Scrum Terms

2011-12-11T03:48:00.001-08:00

Defining Scrum: A Compilation of Scrum Terms

Scrum, a software development process developed by Hirotaka Takeuchi and Ikujiro Nonaka in 1986, has become highly popular as a general product development framework in today's businesses. If you're looking into trying this methodology, here are a few key terms that you need to familiarize yourself with before you get started.

• Product Owner - The "Product Owner" represents the customer's voice in the development process. The "Product Owner" is actually a member of the development team who researches customer opinions and stories, and adds them to product backlog for the team's reference.

• ScrumMaster - The "ScrumMaster" (or "Scrum Master") facilitates the entire process. He or she serves as the buffer between the team and impediments or distractions, keeping the team focused on the current tasks. A ScrumMaster can also act as the Product Owner if ned be.

• Teams - The teams involved in this methodology who have cross-functional skills that can used to do the actual development work, including analysis and research, design and development, testing, and even documentation. Scrum teams typically have 5-9 members in them, and are usually self-organized (though team managers/leaders still fall under the authority of the ScrumMaster).

• Backlog - Backlogs are lists of tasks that the team needs to work on. There are two types of backlogs: the product backlog, which is the overall list of what needs to be done during the entire process; and the sprint backlog, which is a list of tasks that need to be completed during the sprint.

• Sprint - Sprints in scrum methodology are time periods wherein the actual action and development occurs. They typically last for 2-4 weeks, and the tasks to be accomplished during each sprint are based on the sprint backlog.

• Sprint burn down chart - This is a checklist of tasks that is updated on a daily basis during a sprint. This is displayed in such a way that all the team members can see and update it easily, and keep track of what remains to be accomplished.

• Daily scrum - Short, daily meetings that occur during a sprint. During this meeting, the team discusses what was accomplished the previous day, what needs to be done, and any problems or impediments that are hindering progress.

• Sprint Retrospective - A longer meeting that occurs at the end of a sprint, wherein team members get together to discuss the previous sprint and how the next one can be further improved.

Scrum and Agile Manifesto

2011-12-07T23:03:00.001-08:00

Scrum and Agile Manifesto

Some people start using Scrum although they know almost nothing about the Scrum. It makes me really sad when I meet people with the following mindset "Scrum == Sprint". Yes, all they know about Scrum is that you have to work in some iterations called "Sprint". And at the end of the project they are so disappointed because the project was not as successful as they expected. That is because the Scrum is dramatically different from traditional sequential development.

Every Scrum team member must be familiar with the basic values of Scrum. That's why I decided to wrote 12 posts about the foundation of all agile methodologies including Scrum: Agile Manifesto Principles. In every post I try to will explain one principle in a very simple way.

Here is the first principle:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

At the start of the new project you have to answer one really big question, what exactly are we building? The short answer is, that you must build the software that is going to be of value to the customer and will satisfy their needs. But in the reality it is not so simple to achieve that.

In the sequential development project you would first start with a lengthy up-front requirement-gathering phase. The result of this phase would be hundreds of pages of detailed requirements documentation where all features are equal important. Let's face it, the customer don't care about documents and UML diagrams and it is hard to get the right information from the customer and put it on the paper. They just want to get the software that maximizes the added value to their business and they don't know exactly what that value is on the first day of the project. There is a big chance that there will be some disappointment on the customer side when the software will be presented for the first time at the end of the project, although the software works as at it is described it the documentation.

There is a total different story with Scrum teams which adapt early and continuous delivery of valuable software because the client is involved throughout the lifetime of the project. That is how you can get early customer feedback and valuable emergent requirements. Scrum team documents all the features in a product backlog, which is a master list of all desired functionality not yet in the product. Product backlog is also known as prioritized feature list and priority is assigned based on the items of most value to the business or that offer the earliest ROI and value. Product owner has to groom the product backlog continuously because items are added, removed and reprioritized each sprint as more is learned about the product being developed. The result is that the most important and highest-priority items are implemented first because they are found at the top of the product backlog.

Agile Changing Requirements

This is the second post in the series of 12 posts about Agile Manifesto Principles. They are the foundation of all agile methodologies and every Scrum team member should be familiar with them.

Here is the second principle, that talks about change:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

In software development we all strive for a projects where customer would never change their minds. And we all know that will never happen because changes are inevitable in real world. Customers usually do not see a problem of changing requirements as a serious one.

Traditional development process prefers sticking to their well-thought-out plans that are the result of the requirement-gathering phase. Introducing change late in the development process is costly because you need to repeat the whole waterfall process (analyse, design,...) for each change.

Agile methods take a different approach and treat change as an expected and welcome part of every project. After all, it is all about satisfying the customer because it is necessary to preserve customer's competitive advantage.

During the project the customer can continue to make changes, as long as they prioritize these changes in the appropriate iteration. Product owner is responsible for understanding of the customer needs and grooming the product backlog (prioritizing work based on business value) even near the end of the project. It is even better to make decisions later in the process when we have a better understanding of the product that we are building. Because a product backlog is a living thing that evolve constantly it can respond to the actions of customer's competitors. Agility is all about flexibility and being open to change is a big advantage.

You need to remember the following two words about this principle: welcome (changing requirements) and harness (change)!

Agile Approach Replacing Traditional Methods of Software Development

2011-12-04T02:16:00.001-08:00

Agile Approach Replacing Traditional Methods of Software Development

There is a lot of debate going on regarding agile software development and whether it serves to be more beneficial or not. Many developers are turning to this methodology rather than the conventional methods to develop software.

The growing trend for this methodology is fast gaining popularity as it proves to be more efficient and result oriented rather than the time consuming traditional methods of the past. Agile methods when put to use have been found to be more productive. Their flexible style suits the modern style of working where quick solutions that save time are what matter most to businesses.

The old engineering methods took too much time in the planning phase alone as everything was worked out beforehand. On the other hand agile processes tackle the problems as they come rather than depending on planned strategic behavior.

The predictive policy as in the older methodologies to plan and then build is not very useful as estimates can turn out to be very inaccurate when the actual execution takes place. Plus the requirements can keep changing and therefore a fixed plan might not work. Agile methods are more open to change. Very often it is during the process that it is discovered which aspects are more valuable and which can be compromised on. In agile processes such adaptations can easily be made.

Iterative development keeps the process simple as a certain phase when completed is forwarded for feedback ensuring continuous and smooth flow of work. With proper intervals of feedback and immediate responses for every phase you can move on with every step with proper checks thus fixing the bugs as they come along. Iteration development allows building a strong foundation on which you can base the next developmental phase.

In agile development the software design process becomes more people or team oriented as it is the team members who evolve the strategy as they seem fit according to the technological project demands. The software processes are not predetermined and the power of decision lies not with one management figure but the team that is working on it.

Although there are many benefits of agile development and it is widely applicable it might not prove to be fruitful in all case scenarios. Many believe that as agile is dependent on team work that requires quick immediate responses it cannot work well for large projects or for offshore development processes. Contrary to this there have been successful agile developments for offshore projects.

Implementing an Effective Software Development Process: Agile, Scrum, CMMI and Where to Start

2011-11-25T06:37:00.001-08:00

Implementing an Effective Software Development Process: Agile, Scrum, CMMI and Where to Start

The first problem when reading through the literature about agile and scrum: it seems overwhelming. Reading about CMMI sends you even further into the bush. The large IT providers easily assign some people to study, master and implement such complex processes. But the biggest part of the software industry consists of small and medium sized firms. In Europe, the biggest part of the software firms have somewhere between 10 and 50 employees. If you work at such firm, you probably want to get going, produce and get your projects ready. The thing on your mind is to get that new product release out on the market, to speed up your project to make a deadline. You don't have the time to learn a new process, think everything through, document it and implement the change.

The common way of organizing software projects in most software firms is (or was) the waterfall method. Most firms don't choose this process deliberately, but grow into it, because it's a natural human way to get organized. It has its parallel to the construction world: you have an idea of your dream house; you hire an architect who captures all your ideas and puts it into a drawing; the drawing gives a very clear picture of the house and matches with the picture in your mind; you accept the drawing; the drawing goes to the construction firm who tells you what it'll cost to build the house; and so the project starts. In most cases, the construction firm gets it right: the house is like the picture. What they frequently don't get right is the timing, but as we've grown accustomed to that, we accept the delay and we're happy to move into the new house.

I think there are 2 crucial differences between construction and software development, which agile and scrum address:

It is very hard (maybe even impossible) to clearly picture the software application before it exists
It is much harder to organize, because the thought process and the execution don't follow linear patterns
Whatever process you want to implement, however you call it, there are two things that can improve a software development process drastically (those two are also central parts of scrum and agile):

1. Create the picture in steps instead of upfront.

For smaller projects, this might be over-organization, because the picture can be made clear upfront. For bigger projects, it brings substantial improvement. Define the high level requirements of the project (create a rough picture), then cut out a part that can be completed within two weeks. Divide that part into clearly defined tasks and start building. Anything that has been built in those two weeks has to be tested and reviewed thoroughly and based on the results, the part and tasks for the next two weeks are defined. This gives a more flexible approach to building the picture and gives an opportunity to 'steer' the project in the right direction.

2. Organize communication

In the waterfall method (and the natural human organization method), the requirements are supposed to be clear, so we let the programmers do their work and expect to see the result when the deadline is due. Whatever happens in between, we expect them to fix. The problem in this organization is communication or the lack of it. Scrum and Agile have daily meetings as its cornerstone. Every day at a fixed location, with fixed people on a fixed time, the team discusses three questions: 1. What have you done yesterday?; 2. What will you do today?; 3. Where are you stuck?. Especially this last question is what brings a leap in productivity. Programmers often bang with their heads against a closed door. If you don't hear them banging, they sometimes keep doing it for a week, believing that they'll catch up the time they lose later on, trusting that they'll get through that door. Daily meetings ensure that everyone hears the banging and puts the brains of the team into opening the door.

From these two, the second has the biggest impact and is the simplest to implement. If you are not ready to implement a whole new process, start with organizing communication. While building a house, the supervisor walks around daily and will see it when someone can't get the door in place. He will walk to the person and ask what's happening and will organize help to fix the door naturally. In software development, the door is invisible, the solution to fix the door is not straightforward and programmers find pride in solving complex problems and will try anything (for days in a row) to solve it. Communicate, ask the three questions every day and your projects will start moving faster and more fluid.

Agile Software Development, 6 Advantages

2011-11-23T03:14:00.001-08:00

Agile Software Development, 6 Advantages

Agile development is a strategy of software development in which the process occurs though short increments. The phases of the development process occur continuously in iterative cycles, involving a requirements phase, design and implementation, testing, and reporting. Stakeholders and designers meet after each increment to discuss what has occurred, re-evaluate requirements and determine priorities. This allows for greater transparency between clients and programmers and clients have greater influence in what is being designed to ensure the product is what they want. The traditional waterfall method general involves the stakeholders at the beginning requirements phase, and then the development company takes over and designs the website. The stakeholders or clients only see the finished product, which may or may not be what they had in mind. There are many advantages to agile development over the traditional models.

1) Agile development reduces the risk of client dissatisfaction

Since the stakeholders are involved in the process the entire time, the agile model reduces the risk that the product will not meet the needs of the client. When the stakeholders are only involved in the requirements phase, they may not see that certain aspects of the design do not work or are irrelevant to their customer base. With everyone working together and continuously re-evaluating, the project is more likely to produce a useable product.

2) Allows for more change and adaptation

In the agile development method, the large, irreversible project elements are delayed until the last moment so as many changes as possible can be made to make sure the project is exactly right. Changes can be made after each increment; the designers are not stuck with one model. Agile development is very adaptive to the changing needs of the client, the developers and the available technology. Because requirements can always change as new software is developed, these changes can be incorporated into the project instead of making the design obsolete before it ever goes to market.

3) Work can begin before all the requirements are known

Clients may not know everything they want in their finished product, but with agile development, they do not have to wait to get started working on the software. They can start with a basic idea and because they are included throughout the development process, they can add requirements as they decide what they need and based on the work that has come first. Clients can continuously reprioritize so they have a usable product in a shorter amount of time

4) Increases likelihood that a project will reach the marketplace

A large amount of development projects never make it to the marketplace for various reasons including it was not what the client wanted, it is now obsolete, or it is not useful. Using the agile development method, the chance that the product will go to the market is actually much higher because the chances that the client will approve of and find the product useful is higher. Also, the software developers can develop the highest priority designs first, allowing the product to be used immediately, even if it is not in its completed form.

5) Saves time and money

Stakeholders are involved in agile development throughout the process and everyone is working together, so the chance for miscommunication and incompatibility are smaller. This saves time by resulting in fewer mistakes and it saves money because the project is finished faster. Once a client makes a decision on a requirement, they can see results quickly. The client will see results after each iteration and determine if the software meets their needs. Less time is wasted on features that are not going to be used.

6) Works well with distributed teams

Agile development is a method that can work when part of a project is outsourced, but is infinitely more successful if outsourced to a team in the same time zone. By having constant contact with the outsourced team, there will be fewer mistakes and miscommunications. With nearshore outsourcing, the developers and outsourced team are working in the same time zone and language. People in other countries can easily keep in contact via email, phone and video conferencing. Agile requires more communication and more communication results in fewer mistakes and misunderstandings.

Agile Development Software: Flexible Results Delivered in Small Time Blocks

2011-11-18T00:13:00.001-08:00

Agile Development Software: Flexible Results Delivered in Small Time Blocks

Agile refers to a specific methodology used when developing a business application solution. This type of development actually includes methodologies designed to enhance organization through multiple self-reliant teams. Adaptive planning, time-boxing, and response flexibility are promoted when using this method to create software. It is based on the concept that interactions will occur during the development cycle and accommodates for these road bumps. Agile development software may be created through one or many sub-methodologies, with each of them promoting the same basic items collaboration, teamwork, and adaptability.

Small timeframes allow a set of tasks to be completed in as little as one week or as long as four weeks. Planning, analysis, design, documentation, programming, and testing are all included per timebox. This constant circling allows teams to adapt quickly to changing requirements and better meet the demands of each client. The product is displayed in its entirety at the completion of each cycle for suggestions or the addition of new requirements. Agile practices allow a full version to be available for deployment at any time.

Scrum Offshore Advances the Turnaround Time of Outsourced Projects

The scrum offshore approach lets teams be increasingly cross-functional, and it promotes self-organization. Corporate hierarchies and other debilitating factors are removed, making it easy for each team to make the best decisions regarding single development iterations. Open communication between smaller teams makes it easier to continue advancing the functionality of a revolving software product. It is different from the waterfall methodology because it does not contain four unique phases: business requirements, system design, development, and implementation.

Agile methods keep the customer involved throughout the duration of the project, whereas traditional approaches only take the requirements from the customer to complete the designs used for the final product. Once this information is gained, the client really has not further role until the finished result is demonstrated.

Scrum offshore practices are a single example of agile practices applied to provide significant advantages when the needs of a business change frequently or are not completely known. With scrum, all requirements reside in a backlog used to determine the tasks for each upcoming sprint or timebox. It is an iterative methodology where tasks must be completed in the timeframe. Those development tasks not completed in the set time are input back into the backlog to be tackled again. It still consists of a revolving cycle just as any agile approach and can meet the continually changing desires of a client.

Scrum practices are typically grouped into the category of rapid application development (RAD) due to their iterative nature. RAD has one main objective-to create a high quality solution quickly without an extensive investment cost. Risks are often reduced due to the project being broken down in smaller more manageable tasks. The application is not a prototype, but instead production software the client can use at the end of any iteration. All documentation needed for future alterations is provided throughout the development of a solution. Agile development software offers a business the benefits of increased turnaround time, increased customizability, and on-demand deployment.

Functional Testing - Testing Software From a Functional Point of View

2011-11-16T06:54:00.001-08:00

Functional Testing - Testing Software From a Functional Point of View

Functional testing - the first, basic level of 'Testing' that is expected out of every Software Quality Assurance Professional. And even though it is being conceived as somewhat of a 'technical weakness' in many circles, functional testing is the core of all testing domain. The primary objective being, as the name indicates, is to provide quality assurance of the software from a functionality point of view. What you see/view on the screen, you need to 'test' it. It could be a Java API or it could be a.net web service. You need to validate what the interface is supposed to provide you. Often you will not be told a lot about the business requirements, and yet you are expected to come up with a very good 'tested' software product.

There are several steps which are needed before 'functional' testing can be completed. First of all, before you begin any testing you have to come up with a 'test plan'. A test plan is like a formal document which contains the steps and the procedure undertaken by the Software Testing team in order to fully test the project. Once the plan is approved the team will proceed with the test route. And it always starts with functional/manual testing. All of the requirements need to be understood before you can start testing, and that is very important. In my five years of experience I have seen many projects that were over budgeted and failed to get the expected response out of the clients due to this very reason, that the exact requirements were not understood properly by the testing staff. If there is confusion/lack of understand related to business requirements, the business flow will not be properly understood and that will lead to problems. As the client will expect the business flow to be tested before being delivered to the end-user. That said, the requirements are subject to change and they have to be managed by the project manager.

Once the requirements are understood (and it is an ongoing process), the testing team can begin with their 'test scenarios' a process by which test scenarios are identified and noted down. In this case it is pertinent to mention that one requirement or business case can point to one or more than one scenario. For the scenario, it is almost a requirement that there is an input (or more than one) and an output (at least one). Once the scenarios are finalized, the testing team can proceed with the test case part. Once the test cases are written down in document form (they can be written in MS word document, or it can be entered in a test tracking tool like Mercury's Test Director or JIRA), they result in defects or suggestions/improvements. These defects are prioritized and worked upon and eventually it leads to regression testing, where the test engineer has to re-test the defects again to verify the fixes.

The stability of the application at hand is the most important aim of all this testing activity. As the application is stabilized, it becomes easier for the client to make good out of it. Thereafter the requirements change and accordingly the application has to be customized to satisfy the changes requested. The other testing forms, such as automation, integration, compatibility and so forth are all a result of the functional testing cycle. If the application has not been properly tested in the functional phase it is very unlikely to be automated.

To conclude, functional testing is the core of all testing forms, and it's a vital part of any software project. Be it an ERP or eCommerce website or any other software project.

Software Development - The Quality Check list

2011-11-14T05:59:00.001-08:00

Software Development - The Quality Check list

Quality Essentials

If your business is software development/production, whether for external clients or in-house, then it is essential that you have the following elements and structures in place.

Below is a list of essential elements, whether you are building a package for mass distribution or a one-off application for a specific client.

System Development Cycle

From inception to implementation, this should be a fully documented set of stages that each software development will go through, listing the tasks and products for each stage.

This would comprise, as a minimum, a function hierarchy defining, in terms of business functions, what it is that the software will do. This will be broken down to the level of Elementary Business Function (EBF) for each function to be implemented by the application. Full function logic and data usage will be defined for each EBF.

Data Model

This model will include as a minimum:

An entity relationship diagram (ERD) covering all entities used by functions that will be implemented by the application.
Definitions for all entities, including full descriptions
Definitions of all attributes and their formats
Definitions of the unique identifiers for each entity
Design Standards and Guidelines

A fully documented set of rules and standards for converting functions to modules and data model elements to database elements.

Module Definition

Each module in the application must be defined in terms of the form it will take (screen, report or procedure), the programming language to be used, the function(s) it will implement, what the access rights are for the module and the module logic based on the logic of the function(s) its implements.

Database Schema

As a minimum this will comprise:

A diagram showing all tables in the database and the relationships between these as implemented by foreign keys.
A definition of each table in terms of the data entity it represents, its columns, their formats and what attributes they represent, primary keys, foreign keys and a definition of how unique identifiers are to be implemented.
Menu Structure

A defined menu structure defining how each module of the application will be accessed and the access rights, based on the module access rights.

Programming Standards

A documented set of standards defining language(s) to be used, preferred programming structures and those to be avoided, commenting standards, interfacing protocols.

If you have all the above in place then you are in good shape.

If not, you ought to put them in place as soon as possible.

Quality software systems cannot be built and maintained without them.

The Difference Between a Software Developer and a Computer Programmer

2011-11-13T07:58:00.001-08:00

The Difference Between a Software Developer and a Computer Programmer

So just what is the difference between a software developer and a computer programmer? These job titles almost seem like they should be interchangeable, but there are some key differences between the two. If you are studying to enter the IT field you should definitely know what these two jobs are like, so you can decide if either of them is right for you.

Computer programmers are responsible for developing, maintaining and testing codes based on the software specifications of their employers or project managers, as well as other duties related to designing and maintaining websites. To be successful in this field, you must have good analytical and organizational skills, proficiency in math and science and the ability to follow directions and work as part of a team or alone. Computer programmers may be required to create reports and perform other necessary but sometimes tedious tasks, so you must have a good work ethic and team spirit to make it far in this field. Deep understanding of hardware and software, as well as the leading programming languages, is a must.

Software developers, also known as software engineers, are responsible for developing, maintaining and testing various software programs for companies, governments and other organizations. These trained and skilled professionals must be proficient at the design, development, maintenance, requirements and testing of software. The most successful software engineers/developers are able to use a rigorous approach to development and successfully master all the methods and tools of the trade. They can have teams working underneath them, or they may work alone; either way the job requires project management, communication and accountability skills in addition to technical know-how.

Computer programmers are more likely to work for someone else or as part of a team, whereas software developers or engineers are more likely to work alone or as the leader of a team. Either role is important and vital to the success of the organization, but some people are better suited to one as opposed to the other. If you think one of these jobs might be right for you there are many degree programs to help you take the next step.

Quality Certifications and What they Mean in Software Development

2011-10-29T22:25:00.000-07:00

Quality Certifications and What they Mean in Software Development

Large scale software development companies are still quite young and the software industry itself is a fairly new one. Outsourcing of software development has been around for only a couple of decades and as the industry gains maturity, quality certification has taken on a whole new meaning for suppliers as well as customers. Quality certification in software is slightly different from quality certification in manufacturing. Though a number of business process management and quality control principles are derived from popular quality certifications, the implementation and implications are noticeably different.

There are two broad types of quality certifications which can be obtained by software development companies. One is the ISO 9001:2000 standard and the other is various levels of SEI CMM. Some organizations may achieve an ISO first and then work towards an SEI CMM level certification whereas some may go directly to an SEI CMM certification. ISO certification however, is a lot easier than SEI CMM (as well a lot cheaper) and thus the number of companies with ISO certifications are quite a few whereas SEI CMM level companies are not so many in number.

One of the key benefits of quality certification in a software development company is that it showcases the maturity and continuity of the organization. Both quality certifications pay attention to processes. ISO guidelines state that you should define a process and make sure that it is being followed whereas SEI CMM dictates certain parameters of a process within which the company should work. Achieving certification and maintaining the documented processes provides a long term growth pattern in the company and at the same time helps in building a differentiating factor with customers.

Apart from the maturity and continuity of the organization, software development companies need quality certification to ensure the success of large projects. Tried and tested development methodologies which are part of the certification process ensure that the coding and designing produced by the company are of a high standard and will withstand the test of use and durability. Customers planning to do business with a quality certified company find it much easier to get a good quality software product. Non-certified companies have a tough time when competing with a certified company and that is the reason why more and more software development companies are moving towards quality certification.

Most medium to large companies are moving towards SEI CMM level certification as that quality certification has been developed with software development in mind. There are various levels of the certification and level 5 is the highest a software development company can achieve. The entire certification process for SEI CMM level is lengthy, time consuming and quite expensive when compared with ISO 9001:2000 but the benefits compensate often compensate for that.

So if you are a software company and have not yet gone down the path of certification, it is time you gave it serious thought. If you are an organization looking to outsource software development work to companies in India, China, the Philippines, Poland or parts of Eastern Europe, it is advisable that you consider their quality certifications. Though we have mostly mentioned ISO 9001:2000 quality certifications, there are other industry and technology specific certifications which can also be obtained by software development companies. Usually these certifications are given by software manufacturers or independent bodies and though they might not be as critical as the quality certifications mentioned, they have a good level of importance when evaluating a supplier.

Software Testing Interview Questions

2011-10-25T06:39:00.000-07:00

Software Testing Interview Questions

I am not suggesting that these are the only questions that would be asked, but are some samples for consideration. These are questions that I have used when interviewing others:

1. How many test scripts can you write in a day?

I am looking here for the ability to estimate. Whilst in reality the question is impractical, because it depends on so many different factors, I want to see the interviewee come up with some kind of answer. When estimating, there is a need to make assumptions and having a ball park figure enables someone to provide rough estimates more quickly.

2. How many test scripts can you execute in a day?

This is a repetition of the first question. I normally ask one directly after the other. The more junior resources tend to struggle with the first question and then the second also. The better resources learn from the experience of the first question and respond in a more positive manner to the second. Now I am not only looking at the ability to estimate, but also the ability to learn and an indication of the resources chances of seniority going forward.

3. Do you see testing as a service or a discipline?

Personally I am quite passionate about this one. I very much see testing as a discipline and a part of the software life-cycle that is as important as analysis, design and development. What I am trying to understand is the background that the individual someone has come from. Consultancy can demand one or other mindset and someone coming from either background can adapt, but I would suggest it is easier to revert from discipline to service than vice versa.

4. What is the most interesting defect you have found?

This is a passion question. I am looking to see if the individual can recount a particular incident and in what degree of detail. This begins to tell me whether they are a career tester or someone who is doing a job.

5. What are the key components of a test script?

Someone who is raising scripts every day should be able to define what information is required to be recorded. Different organisations have different standards, but there are key aspects to the answer. The requirement should be referenced or potentially included showing understanding that scripts should always be traceable to their point of origin. The script should have steps through, each of which defines the action to be taken, the data to be used and whether the step has passed or failed. This is the most basic of information and fundamental to all testers so an inability to provide this information is probably going to fail the candidate.

6. Can you define Black, White and Glass box testing?

This question is used to understand whether people have a basic understanding of testing jargon, as well as having attended the ISEB Foundation in Software Testing, where Black and White are covered. The inclusion of Glass box testing throws some people completely, others will think about it and try to define the answer; some will immediately define Glass box as being the same as White box.

Scenario Based Questions

You are the test manager on a project. The code is going to be delivered late and you now need to complete four weeks testing in two. How are you going to cope with this?

I am looking for managerial level thinking and understanding. There are numerous ways of dealing with this, more staff, overtime, weekend working, shift working, risk based testing, reduction in deliverables. The question is how many can they come up with and do they understand how to achieve them and the associated problems.

Risk Based Testing - How are they going to achieve this? Are the tests already grouped by risk? Are the requirements already grouped by risk or have the risk identified against each.

More test effort - Whilst increasing test effort is a simple means of achieving more in the same time frame, there needs to be a realisation that other departments will also need to apply similar Resourcing, to cover out of hours working, to handle increased volumes of defect fixing.

Cost Implication - Does the person discuss the increase in cost that can be associated with their suggested course of action? Are they thinking at project level or something lower?

Importance of Software Quality Assurance

2011-10-18T07:59:00.000-07:00

Importance of Software Quality Assurance

In this competitive age, Software quality assurance is an inevitable part of the software product development industry. Every IT company performs various activities and follows various strategies to ensure the quality of their product.

Software quality is one of the pivotal aspects of a software development company. Software quality assurance starts from the beginning of a project, right from the analysis phase.

Software Quality Assurance (SQA) is defined as a well planned and systematic approach to evaluate the quality of software. It checks the adherence to software product standards, processes, and procedures. SQA includes the systematic process of assuring that standards and procedures are established and are followed throughout the software development life cycle and test cycle as well. The compliance of the built with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, project management etc.

The major reason of involving software quality testing in the process of software product development is to make sure that the final product built is as per the requirement specification and comply with the standards.

Requirement analysis and definition
Design architecture and description
Coding and logic analysis
Change and configuration management
Testing and standard compliance
Release management and Release Control

Different activities of Quality Assurance are the following:

Maintaining the quality of the project as per the specifications and business requirements.
Defect Prevention. And formal methods for other defect prevention techniques
Defect Reduction
Inspection, formal and informal reviews: Direct fault detection and removal without executing the project scenario.
Testing the project for Failure observation and bug removal.
Risk identification.
Defect tracking techniques and methods
Software fault tolerance.
Concluding Remarks and maintaining reports.

Software quality assurance is concerned with building software products with required quality and maintaining the level of quality. Software processes are important paradigm in achieving the software quality. The software quality assurance (SQA) key process area of the capability maturity model (CMM) consists of activities for keeping track on adherence to the processes and specifications. The term SQA sometimes creates confusions with the quality management concepts. Software quality can be quantified into two major groups such as:

Software functional quality: It basically shows how well the software product conforms to the basic design, based on functional requirements. The attribute can also be described as the fitness for purpose of a software

Software structural quality: It reflects to how well the project meets the non-functional requirements such as usability, accessibility and security that helps in proper the delivery of the functional requirements. It basically defines the degree of correctness of the product.
The Structural quality of a product is defined by the analysis of the software inner structure and its source code. The reason for structural software quality analysis is to check the adherence of the product with the software architecture specification. It is carried out by the developer of the project. In contrast; functional quality is all about checking the functionality adherence with the requirements specification and is measured through software testing.

The major principles required for any software product for quality and business value fulfillment are Reliability, Efficiency, Security, Size and Maintainability.

+1 FOR Like this article thank all

The Gantt Chart: Already Dead Or Still Alive?

2011-10-03T07:56:00.000-07:00

The Gantt Chart: Already Dead Or Still Alive?

Recently, I was confronted with the provoking statement: "Henry Gantt is dead since almost 100 years, and virtually his charts are too." I did not reply, but decided to give this a thought.

The hypothesis that something is considered to be dead automatically implies that it had been alive before. As we are not talking about a person here but about a visualization technique, dead and alive in other words mean that this technique had a value in the past but is regarded as no longer needed nowadays. Hence, it can be worthwhile to lock back into the past when a Gantt chart not only was seen as valuable, but also as revolutionary tool. This may reveal some more insights why it might have died since then.

The environment, for which Henry Laurence Gantt invented his charts, was the production industry and the prime use case was the improvement of managerial decision-making in the scheduling process. The design of the Gantt chart followed the question which information a foreman or supervisor needed to see in order to quickly understand whether a production was on schedule, ahead of time or running late. Gantt introduced the idea to use time and resource usage and no longer quantity as a yardstick for making scheduling decisions, and created various types of charts depending on the individual needs of the production managers. These executives at that time had to manage bottlenecks, were supposed to deal with uncertainty, and needed to cope with all problems resulting from the still high degree of human contribution to industrial production. For this environment, Henry Gantt created a chart that summarized all relevant information at one glance to enable managers making profound scheduling decisions.

In a nutshell, the Gantt chart had been alive when the following characteristics were met: It had to be production environment where decision support for scheduling processes were needed and required context-sensitive information ("for individual needs") at one glance taking into account time and resource usage as crucial determinants.

What has changed since then to declare the Gantt chart dead?

Although we are heading towards the so-called service society, the cumulative net output of the manufacturing industry still counts for more than 25% of the global GDP (source: World Bank). Undoubtedly, this sector still has its relevance. Competition is increasing and many products more and more become a commodity. Both trends drive a margin pressure especially in the manufacturing industry. This allows making the initial assumption that scheduling processes have become even more important, and as such the tools providing decision support for scheduling tasks.

This assumption can be endorsed by three core evidences: First, it seems to be common sense that time is a key success factor for production companies. An underlining evidence for this common sense can derived from looking at common key performance indicators such as time-to-market or production methodologies like just-in-time. This raises the question why a time-focused scheduling tool is regarded as outdated. Second, since the good old days of Henry Gantt the ratio fix costs to variable costs has been becoming more and more fix cost-savvy. This is also and even true for production environments. In fix cost-intensive areas, people typically have to put a high emphasis on the best possible resource usage to make maximum use of the fix cost-driving capacities. Again, the question needs to be raised why a resource-focused visualization to support scheduling decisions should be outdated in such a scenario. Third, one needs to look at decision support itself. The delivery of context-sensitive information has arisen as one candidate for becoming a new paradigm for the design of decision support systems. This becomes even more relevance if one takes the tremendous data growth into account. Henry Gantt intended to create exactly this. His charts were meant as a context-sensitive tool to improve time- and resource-based scheduling decisions. For the third time the question needs to be raised why this is considered as outdated. The opposite seems to be true: For manufacturing companies, there is more need for a Gantt chart than ever before.

Finally and fair enough: many of "the Gantt is dead" advocates come from the project management industry. This specific use case of a Gantt chart has not been analyzed here. The focus here was to prove that the Gantt chart as Henry Gantt invented it, still is alive and needs to be alive in the production industry. I feel, this question has been clearly answered.

Gantt Charts Structure and Function

2011-10-01T05:50:00.000-07:00

Gantt Charts Structure and Function

Gantt Charts are used in Six Sigma to show the schedule and track progress in completing tasks. These visual representations of work to be completed are special bar charts with information for the project manager. It is easy to read them and see at a glance the time goals of what is going on in the project.

A simple breakdown of the Six Sigma project sorts it into smaller tasks to be completed. The tasks are labeled. An approximation of the time needed for each task is derived by a formula of (the optimistic time needed) + (4 times the expected time needed) + (the pessimistic time needed), divided by 6. This is the time frame indicated in this type of chart.

The tasks are broken down in a way that defines which ones must be completed before others must be started. The information is gathered and incorporated into the Gantt chart. The beginning of a task is indicated by the beginning of a graph line, and the ending of that task is shown by the ending of that line.

The Six Sigma tasks go in succession from top to bottom on the graph, with the end of a task line for a task that must be completed first connected to the beginning of a task line for a task that must be completed next. This creates a chart where the work stream flows from top to bottom with tasks to be completed, and left to right with time periods to complete them in. The end of the Gantt chart is at the right bottom, at the end of the task and the end of the time.

Gantt Charts can and should be modified all along the process to show the actual progress of the project situation. Otherwise, they are of little use in Six Sigma. It is too easy to look at the Gantt Chart and think that the task is going well, when you have actually gotten quite far behind. Conversely, it is possible to find yourself coming up on a new task without being ready for it because you have not kept up with your Gantt chart visual.

Gantt Charts can be used for both planning and tracking how those plans play out. They can be used to keep the project manager and the team focused on achieving the goals in the times given. Gantt Charts are very good at what they do best, and that is to show the Six Sigma team where they stand.

Hot Or Not? Developing Applications With Java Programming

2011-09-28T06:07:00.000-07:00

Hot Or Not? Developing Applications With Java Programming

Java is a general purpose programming language similar to C++ and was developed by Sun Microsystems to take advantage of the flourishing World Wide Web. Java programming language is well designed to develop effective web based applications and offers many advantages over other languages like C++. Technically, Java source code files (.java files) are compiled into bytecode (.class files). This complied java code is then executed by a Java interpreter. Since Java interpreters and Runtime environments called Java Virtual Machines exist for most operating systems (Windows OS, UNIX and Macintosh), you can run java based applications on almost every computer!

Portability

As explained Java is platform independent language which means you can write your application on one computer and can run that application on all computers. Java support is built into all major OS and popular web browsers, making it available on virtually every Internet-connected computer worldwide. Even electronic devices like mobile phones, set-top boxes and PDAs nowadays come with inbuilt Java applications.

Efficient Programming and Timeliness

Java is designed to remove common programming errors and comes with excellent set of APIs making it easier for programmers to write bug free code than in other languages. This in turn reduces development time and cost of any application.

Dynamic Characteristic of Programs

Java is object oriented language and the source code is organized in small units called classes. Programs written with Java code automatically call and load these classes whenever it is required to run the application. This means applications written in Java can dynamically expand their functionality by loading these classes anytime from the Java interpreter.

Security

Fortunately, Java programming and platform community is prompt enough in fixing security related bugs. Any new security bug on Java platform immediately catches eye of media because of the promises given by Java community for security!

Like any other programming language, Java is not spared of snags and hitches. Java is an interpreted language and hence programs written in Java language runs comparatively slow. But with availability of faster processors at competitive prices, this barrier should be only a temporary one.

there are many Java web development companies having experienced team of Java programmers to develop quality Java applications with best feasible solutions. They are capable of developing highly interactive web solutions for your business with effective project management support. If you want expert programmers to create competitive Java web applications at affordable rates then India is the best destination. You just need to find right offshore development partner that best suit your business needs and budget. Outsourcing your Java web development projects can save you significant amount of time and money.

Asp Net and Asp Net Software Development

2011-09-25T06:23:00.000-07:00

Asp Net and Asp Net Software Development

Asp.net is a web application development framework developed and launched by Microsoft, which allows the programmers to build dynamic websites, web services and web applications. Released in January 2002, asp dot net is based on Microsoft.Net framework and is the successor to Microsoft's Active Server Pages (ASP) technology. Integrated with SOAP (Simple Object Access Protocol) extension and built on Common Language Runtime (CLR) environment, allows asp dot net components to process SOAP messages and asp.net programmers to write asp.net code in any supported.net languages.

Compiled with the features of SOAP and CLR, allows asp.net software development to support numerous programming languages including C, C++, C#, JAVA/ Ajax, Silverlight and more. It also allows asp dot net with language interoperability, along with CLR environment to execute the programs written in.net framework. Asp dot net is also incorporated with several other features such as user interface, data access and database connectivity, web application, network communication and more. Besides, asp dot net software development decreases the amount of code considerably while building large web and software applications, as well as dynamic website. With its in-built Windows confirmation and per-application arrangement; asp dot net ensures to deliver robust, safe and secure solutions.

More importantly, asp dot net software development provides better presentation of any software or web applications, by taking the advantage of early binding, just in time anthology, local optimization and caching service. Ranging from custom software development to web development and web-based application development, asp.net could provide an array of solutions meeting almost every specific requisites of one's business.

Major Advantages of Asp.net Software Development:

-> Incorporates large library support.
-> Integrations of various programming languages such as C, C++, C#, Ajax/ jQuery, Java, Silverlight and more.
-> Integrated with SOAP extension and built on CLR environment, enabling asp dot net components to process SOAP messages and language interoperability.
-> Includes various other features such as user interface, data access and database connectivity, web application, network communication etc.
-> Reduces the total code amount considerably while building large applications.
-> Asp.net software development provides array of solutions such as
- Custom Software Development
- Custom CMS (Content Management System) Development
- Custom CRM (Customer Relationship Management) Development
- Web-based applications development
- Web development
- And much more...

The demand for cutting edge technological solutions will always be there in the market, wherein the organizations and business enterprises will always try to get their hands on forefront innovation of technology with solutions that allows them to manage their business efficiently and effectively. Encircling these demands, asp.net software development plays an important role by delivering solutions which are not only effective, but are also robust in quality, along with safety and security.

Choosing the Right Programming Language For Software Development

2011-09-23T04:37:00.000-07:00

Choosing the Right Programming Language For Software Development

Software application development is booming currently. The recent years have been of profound skill development, but as the skills have increased so has the need for more diverse software applications to do all different things for varying businesses. With a diversity of programming tasks to perform, programmers need to be careful in their selection of a suitable programming language for the application in question.

If we talk about options, the earlier proprietary methods have now been supplemented with another group of programming tools which have recently become popular as "open source." So now, there are two major groups of web application development languages to look into - open source and proprietary. Open source is a great alternative leading to cost-effective development of dynamic applications. Among the commonly used open source programming languages are PHP, JSP, and Perl, while ASP.Net and ColdFusion are the well-known proprietary technologies.

PHP

It's an open source programming tool that's completely free. However, that's not the only reason why web developers have developed a preference for it. Other major strengths of PHP are that it's plain, flexible, and updated more regularly than other languages by a massive international community of users who developed it and are actively engaged to develop this platform.

ASP.Net

ASP.Net is categorically the most flexible of the web application programming tools. Anyone can apply it with both scripted languages (such as Jscript, VBScript, Perlscript, Python) and compiled ones (like C, Cobol, Smalltalk, Lisp, VB). In addition to that, its flexibility is also apparent in the compatibility of applications with development environments such as VisualStudio.NET, WebMatrix, Borland's Delphi, and C++ Builder.

JSP (Java Server Pages)

Java Server Pages, or JSP, is an open source scripting language that can be consummated without even knowing JavaScript. It is supported by Oracle, so programmers can use Oracle JDeveloper to create JSP pages. It is extensible, and the tag extensions used in this language are straightforward and spotless in form. It allows Java tag library developers to outfit it with simple tag handlers, which is quite a major advantage over other software programming languages.

Perl

It's both full-grown and powerful, which makes it a well-liked open source application programming language. It provides web application developers roughly any tool they need to create dynamic web pages. Another good thing, quite common to most open source languages, is that it keeps benefiting from an ongoing development offered by a large user community, which is also greatly supportive to the developers using it.

ColdFusion

It is another powerful language, presently owned by Adobe. It's easier to get started with it and create forms and dynamic web applications; it could be done with lesser training, fewer code, which means time saving.

Choices are many, but the above programming languages are being principally used to develop successful, proficient software applications. While open source is cheap and is often rather uncomplicated and capable to fulfill the application flexibility need, proprietary is more acceptable when it comes to fulfilling the security, scalability, and complexity demands. Furthermore, it's also important to count on the in-house expertise when it comes to choosing a right tool as that would only determine how the application will be managed in future.

Reusable Software Components - Reinventing the Wheel Over and Over Again

2011-09-21T05:28:00.000-07:00

Reusable Software Components - Reinventing the Wheel Over and Over Again

Even though the old axiom of reinventing the wheel holds true as firmly today as it has done since... well, since the wheel was invented, nowadays with software development it has begun to evolve into something totally different... possibly. In a sense, when you begin to develop a new program, or you want to totally refurbish an old one that has outlived its purpose, you must start by reinventing the wheel again, not once, but many times over.

Sometimes it has to do with all of the different languages that you have to master; VB, C++, C#, Java, VCL Delphi,.Net, whatever, and all of the hundreds of add-ons or hanger-ons that you deal with every day. Maybe it's the rapid advances of technology and an innate human desire to complicate things that are difficult enough as they are. Despite the obvious fact that the computer has definitely made our life easier, it has put all of our life work on the edge of a razor if we should experience a virus attack, a hard-disk failure or total energy blackout in the worst possible moment, but in a sense programmers need to justify their lonely jobs by muddling things up in such a way that only they and Microsoft can understand them.

Anyhow, whatever the reason, those that reinvent the wheel every day, who struggle with cryptic programming languages, who don't integrate well with the normal social crowd, who are an eccentric breed of maverick outcasts, are responsible for what some call reusable software components. Reusable software components? And...?

Well... It's not easy to explain and much less to understand. But these software components or add-ons (or hanger-ons), can save other developers from extremely long hours of reinventing the wheel again, which should give us all a sigh of relief at just the thought of it. With these component software or specific generic programs that can be adjusted personally by each client to their complex business applications, that go anywhere from the design of a new roller skate, through all types of intricate assembly-line processes and can end up as part of the new design for a space shuttle or the next rocket to the moon.

It all depends on your imagination and in that sense only Hollywood can beat them in creativity.
And reusable... well, that is self-explanatory and sounds curiously like something second-hand, which it certainly isn't, but try to remember that programmers are a very strange breed of very intelligent human beings. I should know, I'm the proud father of two shining examples of the species.

The Different Types of Programming Languages - Learn the Basics

2011-09-19T06:55:00.000-07:00

The Different Types of Programming Languages - Learn the Basics

The progression of computer programming languages was made possible by the programmer's search for efficient translation of human language into something that can be read and understood by computers. The languages generated, called machine code, have high levels of abstraction, which hide the computer hardware and make use of representations that are more convenient to programmers.

As programs evolve and become more sophisticated, programmers found out that certain types of computer languages are easier to support. As expected in a dynamic discipline, there is no standard for categorizing the languages used in programming. There are, in fact, dozens of categories. One of the most basic ways to categorize the languages is through a programming paradigm, which gives the programmer's view of code execution. Among the languages classifications according to programming paradigm are:

o Object-Oriented Programming Languages
Known as the newest and most powerful paradigms, object-oriented programming requires the designer to specify the data structures as well as the types of operations to be applied on those data structures. The pairing of data, and the operations that can be done on it is called an object. A program made using this language is therefore made up of a set of cooperating objects instead of an instructions list.

The most famous object-oriented programming these days are C#, C , Visual Basic, Java, and Python.

o Structured Programming Languages
An exceptional type of procedural programming, structured programming provides programmers with additional tools to handle the problems created by larger programs. When using this language, programmers are required to cut program structure into small pieces of code that can easily be understood. Instead of using global variables, it employs variables that are local to every subroutine. Among the popular features of structured programming is that it doesn't accept GOTO statement which is usually associated with the top-down approach. Such approach starts with an opening overview of the system with minimal details about the various parts. To add these details, design iterations are then included to complete the design.

Commonly used structured languages include C, Pascal, and ADA.

o Procedural Programming Languages
Procedural Programming involves a list of operations the program needs to complete to be able to attain the preferred state. It is a simple programming paradigm where every program comes with a starting phase, a list of tasks and operations, and an ending stage. Also called imperative programming, this approach comes with small sections of code that perform certain functions. These sections are made up of procedures, subroutines, or methods. A procedure is made up of a list of computations that should be done. Procedural programming lets a part of the code to be used again without the need to make several copies. It achieves this by dividing programmatic tasks into small sections. Because of this, programmers are also capable of maintaining and understanding program structure.

Among the known procedural languages are BASIC and FORTRAN.

These are the different types of computer programming languages that you can consider when planning to make a computer program. Procedural programming splits the program's source code into smaller fragments. Structured languages require more constraints in the flow and organization of programs. And object-oriented programs arrange codes and data structures into objects.

The Top 10 Website Development Tips

2011-09-16T07:10:00.000-07:00

The Top 10 Website Development Tips

The Internet has now become the powerful marketing medium to promote your business online. Your online presence is established with a professional business website. Web development for your business is very essential if you want to reach more customers.

In order to build a potential website, here are some website development tips that you can follow to reach your targeted customers.

Focus on your objective

When you go for a professional website development, you should be clear with your goals. Keeping the goals in mind before going for website development will let your website focus on your business.

Target prospective customers

Website development alone cannot take up your business to greater heights. More than that, once your professional web de process is over, you must try targeting high prospective customers. This always gives a great lead to your business along with the good website development.

Know customer requirements

Knowing various customer requirements is another way to improve the lead of your business. You can stay connected with your clients through various social networking websites like Facebook, twitter, etc. Once you analyze the customer requirements, try to deliver and fulfill them. Customer satisfaction is also very crucial to run a successful business.

Keep things planned and organized

A successful website development can be achieved only if you keep stuffs well planned and organized. Plan yourself on how you can organize things in website. Jot down, what to focus much and what not. Optimizing the website for search engine is very essential to compete with your competitors in this economic world.

Stay connected with your team

Here is a little tip for you. You can get tons of ideas when you share ideas with your team. They might have ideas and suggestions which might help you make the entire website development process much better. An effective communication between your team and your web designer also helps to improve the website development progression.

Keep track of the statistics

In a website development process, it is very significant to keep track of the statistics. A day by day improvement is to be noted to analyze the time and the resources spent on the web development process. Sometimes, some serious issues may occur. Note down the cause of such situations to avoid them in the future.

Make it easy for the users to navigate.

Easy navigation in a website is very essential in every web development process. It is of no use to the user when you build a website with attractive design with no proper planned navigation. End users may like the website but may not return to your website often. Always a simple and an effective website help both the business owner and the end user.

Your page load time does matter

A website designed, should be optimized for various browsers and connection speeds. In a website development process, there are few things to be considered while developing a website. Image optimization can save you disk cost while the website loads. In a similar manner, usage of div tags in pages can reduce the load time of the page. End users may not wait to view the website if it takes too longer to load.

Typography is the key element

The fonts used in web should be readable and must be pleasing. Remember not to use fonts that are disgusting to read. These make the users to move out of your website. So always use fonts that are pleasant and readable.

Browser compatibility

In any website development process, you must ensure that your website runs on various browsers and operating systems. Because we can determine, which browser will be used by the end users. So always ensure your website is compatible for various browsers such as Internet explorer, Firefox, Chrome, Safari, and Opera.

Changes in Software Development Models

2011-09-14T05:03:00.000-07:00

Changes in Software Development Models

Software needs constantly evolve, demanding such techniques that can offer swift solutions. The methods for software development are undergoing rapid changes. New methods and combination of approaches are being adopted by companies that are fast replacing older and traditional methods.

In the competitive world of today, quick solutions are all that matter as they help you to survive in the industry. No one can afford extensive processes. The old approach requires software to be tested in the last phase. The results in such scenarios come in the limelight when it is too late to make major modifications.

Everyone wants assured results and fewer risks. The best strategy is to keep a check all along the development process rather than waiting for the testing phase. This flexible approach is applicable in agile methods and that is why it is gaining popularity.

The requirements of a software solution in the times we live in change so dramatically that the older, lengthier approaches seem incapable to respond to the fast pace of changes. The traditional methods prove to be either too slow or rigid and unrealistic.

Another aspect is that when the requirements cannot be predetermined, the results cannot be determined as well. Each phase of the development process cannot be pre-planned and a predictive policy in such cases does not work. The results cannot be perceived beforehand in a constantly changing environment.

The older methods based the entire software development life cycle on the needs that were determined in the planning phase. As it has been observed that the needs can alter depending on the changing circumstances so the older methods like the waterfall methods proved to be inefficient. The emphasis therefore changed from predictive to a more reactive approach. An approach that incorporated and embraced the changes was welcomed.

The modern development processes demand reactive solutions that are capable of responding to the problems as they emerge. New approaches that contradicted the older strategies therefore increased in popularity as they made the development process more active and productive. More people today prefer agile methods because of the speedy and efficient results they yield.

We live in complex times with complicated business needs, which require quick and more vigorous approach than the techniques of the older times. Another technique that many are finding quite suitable is offshore approach that lets you acquire professional expertise from a global platform at a cheaper budget. Offshore development solutions are being preferred by companies, who want expert help without having to invest in infrastructure.

Agile Development of Software: The Different Methodologies

2011-09-13T05:09:00.000-07:00

Agile Development of Software: The Different Methodologies

Agile is a popular way of dealing with software development. It tends to be more customer-centric than process-centric. There are different methodologies that follow this concept. These are Crystal, DSDM, FDD, XP, Scrum, and LSD.

Some Agile Development Methodologies:
Crystal - Crystal Methodology focuses on lightweight and adjustable agile software development. It is run by experienced software developers. It actually has lots of clusters within it (crystal clear, crystal orange, crystal yellow, to name a few). This process pinpoints that every project needs its own set of rules and processes in order to achieve a better project output. Like other Agile methodologies, it also includes teamwork, flexibility, constant communication, and simplicity as its principles.

DSDM - or Dynamic Systems Development Method is an iterative agile development software process which promotes repetitive and client-centric projects. 9 instrumental factors rule this methodology: business needs, constant delivery, prompt output delivery, maintenance of quality, incremental software building, high-level collaboration, active client participation, team empowerment, and integrated testing.

FDD - or Feature-Driven Development follows specific practices such as 'Component/Class Ownership' and 'Regular Builds'. It is short-iteration, model-driven agile development software procedure. It starts with a clear model shape then for 2 weeks, it goes into design-and-build-by-feature iterations. These features are usually lightweight but useful for the client's use. The 8 principles that rule this process are domain object modeling, component / class ownership, inspections, regular builds, development by feature, feature teams, configuration, management, and progress and results visibility. Unlike other Agile processes, FDD already has a short specific description of a feature that should be included in each phase.

XP - or Extreme Programming is one of the famous agile methodologies. XP aims to deliver quality output as quickly and perpetual as possible. The team involved in this team must encourage customer involvement, fast feedback system, regular testing, nonstop planning, and tight teamwork in order to deliver the product in 7 to 30 days. The core values of this methodology are just 4: communication, courage, feedback and simplicity. The 12 supporting practices are small releases, simple design, test-driven development, continuous integration, coding standards, sustainable pace, planning game, customer acceptance tests, pair programming, refactoring, collective code ownership, and metaphor.

Scrum - This is a methodology with broad definition of iterative and incremental project management application. Scrum is increasing in popularity in Agile Development world because of its simplicity. The Scrum involves the scrum master, scrum team, and the product owner. The product owner - client or representative of the client - regularly meets with the scrum master. The scrum master is the overseer of the overall project and is the mediator between product owner and the scrum team. The scrum team has at least 7 member with shifting responsibilities to work with the project. Scrum methodology releases end product at the end of a sprint - duration of 30 days.

LSD - or Lean Software Development is another iterative adopts the practices of companies such as Toyota. The focus of the development is to bring value to the customer at the end of each project. If the customer sees that value, he will buy the product. The driving principles of this agile software development are amplifying learning, delivering as fast as possible, building integrity, eliminating waste, deciding as late as possible, empowering the team, and seeing the whole.

What Is The Difference Between Software Development And Web Development?

2011-09-11T03:56:00.000-07:00

What Is The Difference Between Software Development And Web Development?

Every entrepreneur has to do two tasks at a time - one, to learn more efficient ways to progress fast in the business and second, to promote his business well for winning the attention of prospective customers and preventing them to turn to others. For the best business experience in terms of these two, he has to gauge what exactly he requires for the different needs that arise per se: a strong web presence, a responsive web application, a desktop application, and whatever. At such junctures, many business doers realize that web development and software application development may not be the same. Knowledge will only do good to you, better than getting a software made to work on your business infrastructure when you actually needed a web service. Let me differentiate the two for you: the software development and the web development.

Software development can be a part of web development, but web development is not always so. When you need a website or a web segment to run on it, you are looking for website development services. But, if you want a program that runs only on your PC or all the interconnected computers in your organization, you might be on your way to a desktop application or software. So, while a desktop software runs off the web, a web-based software application is intended to run in the web environment.

Most application development companies work on both the types of technologies. Here, you should know that technologies used in web-based activities often get replaced by something superior and more effective than the earlier one. Hence, you couldn't always stick to one that had been done once. As such, the role of a professional application and web developer could come in real handy for you. With his domain expertise, he could give you all the necessary support-based services for all types of your projects.

On the other hand, many business applications are better suited to be run on individual desktops, as they are clearly technologically defined and programmed to a specific purpose and also security concerns and legacy issue come to resolution. This kind of software development is without a subscription fee over the life of the software use. It's made once and purchased outright. Coming to the use of software in a web-based environment, there are a few common procedures like monitoring of online lead generation, customer conversion rates etc. for which a business would require web-based software programs.

Whether applications running on the web or offline and backend apps, both are handled by the professional software application development firms. They would always try to understand the business nature of the concerned firm before they work on any type of development strategy for it. You need not get worried about the quality of work produced by them. Just be clear on your needs and in telling them about the same.

UML Modelling: Activity Diagram

2011-09-09T07:37:00.000-07:00

UML Modelling: Activity Diagram

The activity diagram's purpose

The purpose of the this diagram is to represent the technical flow of events that are part of a larger activity. In projects in which use cases are present, these diagrams can model a precise use case at a more comprehensive level. However, these diagrams can be used independently of use cases for modeling a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data mart populates a corporate sales system's data warehouse. Since it models procedural flow, the activity diagram focuses on the action series of execution and the situations that activate or guard those actions. This diagram is also focused only on the activity's interior actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event.

Although UML sequence diagrams can depict the same information as activity diagrams, I personally find these diagrams excellent for modeling business-level functions. This is because these diagrams demonstrate all possible sequence flows in an activity, whereas a sequence diagram typically illustrates only one flow of an activity. In addition, business managers and business process workforce seem to favor these diagrams more than sequence diagrams -- an activity diagram is less "techie" in appearance, and therefore less threatening to business people. Moreover, business managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.

When to Use: Activity Diagrams

These diagrams should be used in combination with other modeling techniques such as interaction diagrams and state diagrams. The key motivation to utilize these diagrams is to model the work flow behind the system being planned.

Activity Diagrams are also useful for:

Analyzing a use case by describing what actions require occurring and when they should arise.
Describing a complicated sequential algorithm.
Modeling applications with parallel processes.
However, activity diagrams should not take the position of interaction diagrams and state diagrams. these diagrams do not give detail about how objects behave or how objects collaborate.

Definition:

Activity diagrams are graphical demonstrations of work flows of step wise activities and actions with maintain for option, iteration and concurrency. In the Unified Modeling Language, these diagrams can be used to portray the business and operational step-by-step work flows of mechanisms in a system. In this diagram it illustrates the in general flow of control.

Activity diagrams express the work flow performance of a system. These diagrams are parallel to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by presenting the sequence of activities executed. These diagrams can confirm activities that are conditional or parallel.

Structure:

Activity diagrams are constructed from a restricted number of shapes, linked with arrows. The most significant shape types:

Rounded Rectangles correspond to Activities;
Diamonds symbolize Decisions;
Bars represent the start (split) or end (join) of concurrent activities;
Black circle stands for the start (initial state) of the work flow;
Encircled black circle signifies the end (final state).
Arrows run from the start towards the end and represent the order in which activities happen.
Therefore, all these shapes can be considered as a form of flowchart. Usual flowchart methods are short of constructs for expressing concurrency. However, the join and split symbols in this diagrams only determine this for easy cases. The sense of the representation is not understandable when they are randomly combined with decisions or iterations.

Description, meaning, and sequence of the basic notations:

Initial node: The filled in circle is the starting point of the diagram. An initial node isn't necessary although it does make it drastically easier to read the diagram.
Activity final node: The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes.
Activity: The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.
Flow/edge or arrows on the diagram: Although there is a subtle difference between flows and edges I have never seen a practical purpose for the difference although I have no doubt one exists. I'll use the term flow.
Fork: There is a black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity.
Join: There is a black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing.
Condition: In the diagram, there is a text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node.
Decision: There is a diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious.
Merge: There is a diamond shape with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow.
Partition: This is organized into three partitions, also called swimlanes, indicating who/what is performing the activities (Applicant, Registrar, or System).
Sub-activity indicator: The rake in the bottom corner of an activity, such as in the Apply to University activity, indicates that the activity is described by a more finely detailed activity diagram.
Flow final: If there is the circle with the X through it called flow final. This indicates that the process stops at this point.

All About Software Engineering And Development

2011-09-08T05:07:00.000-07:00

Software engineering, known as SE, is the development, design, maintenance and documentation of software by applying practices and various technologies from fields such as computer science, engineering, application domains, project management, digital asset management and interface design.

The conception, development and verification of a software system is what software engineering is all about. It is necessary to identify, define, realize and verify the resultant software's required characteristics. Necessary testing is required for attributes such as reliability, functionality, testability, maintainability, ease of use, availability and portability. In software engineering, software can be verified to meet these requirements by having design and technical specifications prepared and implemented correctly. The characteristics of the software development process are also important in software engineering. Development itself, development duration and risks in software development are examples of such characteristics.

A computer uses software as part of its system that allows the hardware to operate properly. Software can be system software or application software. System software includes the main operating system and a variety of other utilities that enable the computer and its applications to run. Application software includes the computer programs and relevant documentation responsible for end-user data processing tasks. This kind of software is developed for such tasks as word processing, payroll, inventory and production control.

Software Development

A series of processes undertaken systematically to improve a business through using computerized information systems is what is known as software development. There are two major components to software development, which are systems analysis and design.

Systems analysis is the specification of what exactly the system is required to do, or the main objective. Design is about how to make the system do what is required of it. For system analysis, it is required to study the current system by certain procedures in order to gather and interpret data and facts, identify any problems and use this data to improve the system currently in use. System design refers to the process of developing a new system, concentrating heavily on the technical specifications and other specifications that make the system operations.

Software Development Life Cycle

Software Development Life Cycle, or SDLC, is a sequence of events done by designers, analysts and users to develop and execute an information system. There are a number of stages to this practice, which can overlap. The stages are Preliminary investigation (which is feasibility study), Determination of system requirements (which is analysis), Design of system, Development of software, System testing, System Implementation and System Maintenance in that order.

+1 for software engineering blog thank all

Six Sigma and Its Use in Software Development

2011-09-07T07:33:00.000-07:00

Six Sigma and Its Use in Software Development

Six Sigma and its use in Software Development is often referred to as Software Six Sigma. This is a strategy used to improve, accelerate and sustain the process of making programs.

Software Six Sigma helps to speed up the test and integration aspects of product development and allows the delivery of high quality products to consumers. It also improves the predictability and repeatability of the development process. This process applies SPC or Statistical Process Control and other similar applications that are necessary within the test cases, modules, architecture, and requirements. These tools are collectively referred to as the 6 sigma tool kit.

It is used to continuously improve processes and quality, is mainly based on the applications within software development. This process is used to categorize the tools, processes, and product metrics in order to stabilize the process. In turn, it improves the quantitative management relating to product quality.

There are various aspects of this process, such as its ability to correctly measure data, accurately plan development procedures using historical data, use statistical tools in order to provide real time analysis and decisions, accurately quantify the SPC and its benefits and costs, and lastly, to predict high quality products.

This is an effective management program which uses these tools to provide engineers with factual management decisions. Software development is in constant need of problem solving in order to provide defect free products. This process allows engineers to predict issues that may arise based on their probability of happening, which results in less errors overall.

There have been some organizations which still struggle with this process. There are some barriers as it concerns to Six Sigma use in software development. These barriers include:

- Projects are not a very useful or integral aspect of developmental problem solving.
- Training and certification can be a lengthy and time consuming process.
- Poor sponsorship opportunities and complex allocation of responsibilities does not help the product development and process improvement aspects.
- There are far too many competing programs in effect such as ISO 9000, Total Quality Management and Capability Maturity Model.
- Software is inherently different, thus developers are usually able to solve these issues on their own.
- Standard processes do not fully relate to the process of software development.

Although software development and management may differ from what Six Sigma is traditionally used to control, there are still many many applications of Software Six Sigma used today.

5 Defining Features of Great Software Development

2011-09-05T05:46:00.000-07:00

5 Defining Features of Great Software Development

There is a world of difference between really effective and ordinary software development. Customized development of software is one of the principal ways in which business can streamline their business processes, and ensure that their business has growth oriented performance.

So how do you know that the software developed is effective and meets all expectations of the client? There are 5 features that define a successful process of developing software.

1. Software that is in line with client requirements

A client comes to you with a specific set of requirements. A developer needs to understand those requirements inside and out and only propose a solution after getting a clear understanding of client objectives. If the proposed solution is in line with client requirement, only then is the development of successful software possible.

2. Software that goes through the Software Development Life Cycle (SDLC)

Software has to go through its development life cycle in order to be effective. If it doesn't, there might be some key features that it might lose out on. More importantly, there might be certain requirements that might not get fulfilled, if the software project is not taken through the SDLC. The core phases of SDLC include Planning, Implementation, Testing, Documentation, Deployment and Maintenance. If it goes through these phases, the chances of delivering a quality product increase manifold.

3. End User Centric

Software is developed so that its features can be used by the end user. Somebody, in some way or form, is going to operate that software. So, an important feature of successful software development is its user friendliness and the fact that it must be line with the technical competence of the end user. If that isn't the case, the chances of failure increase.

4. Software that is delivered within Deadline

If the development team cannot deliver a project on time, the planning of a client might go haywire. A software project that has gone way beyond the pre-determined deadline starts losing its value. The ROI increases and the software project loses its teeth.

5. All round value

Does the software add value to the existing business processes and contribute to business growth? Does it bring to the client the best of efficiency and quality? The answer to these questions will tell you whether the software offers the kind of value that the clients had asked for, and the end user deserves.

If software comes good on the 5 features given above, it is a product of a great software development process. These features define what such software development is all about. Making use of such software will definitely give a fillip to the business needs of a client.

Ten Top Tips for Creating Good Business Requirements

2011-09-04T01:25:00.000-07:00

Ten Top Tips for Creating Good Business Requirements

Creating good business requirements will go a long way towards ensuring the success of the project and eliminate design and development risks that result from poor business requirements documentation. Here are the Top 10 Tips for Writing Good Business Requirements:

1. Develop a clear understanding of the problems that the proposed software is being designed to solve. This will ensure that the subsequent business requirements document addresses those problems fully.

2. Identify all project stakeholders and involve them in the business requirements gathering process from the start. Work to build trust and establish credibility early on so you can maintain stakeholder support throughout the project. Learn the individual personality traits of each stakeholder in order to be able to better manage them during the requirements phase of the project.

3. Clearly document all business data including workflow, current problems, anticipated risks, and required performance metrics. Use project-approved tools and methodologies to ensure that the documentation conforms to the client's requirements.

4. Use approved templates for all documentation. Ensure that terms used throughout all documentation either exist in the project dictionary or are added as required. No one reading the business requirements document should encounter unfamiliar terms that cannot be quickly resolved by reviewing the project dictionary.

5. Identify potential privacy and security issues early on so these problems can be mitigated to a level which satisfies the stakeholders that these risks have been managed properly. This helps to build trust and ensures that stakeholders remain committed to the project.

6. Make a concerted effort to identify and document all risks, the impact of these risks on the project's costs and timetable. This will avoid unexpected project delays as well as help control runaway costs.

7. Conduct both group and one-on-one meetings to insure that all business requirements, risks and concerns are identified.

8. Present a draft of the business requirements document to key stakeholders for preliminary review and tentative approval. This helps to ensure that the final business requirements document will be more easily accepted by all stakeholders when it is presented.

9. Rewrite the draft business requirements document to address any issues discovered during step #8. This may requires repeating the stakeholder meeting process until you are sure that all issues have been identified and documented.

10. Present the completed business requirements document to all stakeholders in a formal meeting. Take notes in order to maintain the collective project memory and be ready to address any issues or concerns which may be raised.

Choosing the Right SDLC For Your Project Part 2

2011-09-02T07:31:00.000-07:00

Choosing the Right SDLC For Your Project

Waterfall

Waterfall methodology calls for each phase of the development cycle to be repeated once only. Requirements will be gathered and translated into functional specifications once, functional specifications will be translated to design once, designs will be built into software components once and the components will be tested once. The advantage of this methodology is its focus. You can concentrate the effort of all your analysts on producing functional specifications during one period rather than have the effort dispersed throughout the entire project. Focusing your resources in this way also reduces the window during which resources will be required. Programmers will not be engaged until all the functional specifications have been written and approved.

The disadvantage of this approach is its inability to teach the project team anything during the project. A key difference between the waterfall approach and an iterative methodology, such as Scrum or RUP, is the opportunity to learn lessons from the current iteration which will improve the team's effectiveness with the next iteration. The waterfall methodology is an ideal methodology to use when the project team has built software systems very similar to the one your project is to deliver and has nothing to learn from development that would improve their performance. A good example of a project which would benefit from the waterfall methodology is a project to add functionality to a system the project team built in the not too distant past. Another example of an environment that is well suited to the waterfall methodology is a program to maintain a software system where a project is scheduled for specific periods to enhance the system. For example, an order and configuration software system which is enhanced every 4 months.

The waterfall methodology does not lend itself particularly well to projects where the requirements are not clearly understood at the outset. Iterative approaches allow the product owners or user community to examine the result of building a sub-set of requirements. Exercising the sub-set of requirements in the iteration's build may cause the product owners or user community to re-examine those requirements or requirements to be built. You won't have that opportunity with the waterfall method so you need to be certain of your requirements before you begin the build phase. Interpreting requirements into functionality is not the only aspect of development that can benefit from an iterative approach. Designing the system and building it can also benefit from doing these activities iteratively. You should use the waterfall method when your team is familiar with the system being developed and the tools used to develop it. You should avoid using it when developing a system for the first time or using a completely new set of tools to develop the system.

RUP

The Rational Unified Process, or RUP, combines an iterative approach with use cases to govern system development. RUP is a methodology supported by IBM and IBM provides tools (e.g. Rational Rose) that support the methodology. RUP divides the project into 4 phases:

1. Inception phase - produces requirements, business case, and high level use cases

2.Elaboration phase - produces refined use cases, architecture, a refined risk list, a refined business case, and a project plan

3. Construction phase - produces the system

4. Transition phase - transitions the system from development to production

RUP also defines 9 disciplines: 6 engineering disciplines, and 3 supporting disciplines: Configuration and Change Management, Project Management, and environment so is intended to work hand in hand with project management best practices.

Iteration is not limited to a specific project phase - it may even be used to govern the inception phase, but is most applicable to the construction phase. The project manager is responsible for an overall project plan which defines the deliverables for each phase, and a detailed iteration plan which manages the deliverables and tasks belonging to each phase. The purpose of the iterations is to better identify risks and mitigate them.

RUP is essentially a cross between Scrum and waterfall in that it only applies an iterative approach to project phases where the most benefit can be derived from it. RUP also emphasizes the architecture of the system being built. The strengths of RUP are its adaptability to different types of projects. You could simulate some of the aspects of a Scrum method by making all 4 phases iterative, or you could simulate the waterfall method by choosing to avoid iterations altogether. RUP will be especially useful to you when you have some familiarity with the technology but need the help of Use Cases to help clarify your requirements. Use Cases can be combined with storyboarding when you are developing a software system with a user interface to simulate the interaction between the user and the system. Avoid using RUP where your team is very familiar with the technology and the system being developed and your product owners and users don't need use cases to help clarify their requirements.

RUP is one of those methodologies that your organization is very likely to have invested heavily in. If that's your situation, you probably don't have the authority to select another methodology but you can tailor RUP to suit your project. Use iterations to eliminate risks and unknowns that stem from your team's unfamiliarity with the technology or the system, or eliminate iterations where you would otherwise use the waterfall method.

Choosing the Right SDLC For Your Project

2011-09-01T07:01:00.000-07:00

Choosing the right SDLC (Software Development Lifecycle) methodology for your project is as important to the success of the project as the implementation of any project management best practices. Choose the wrong software methodology and you will add time to the development cycle. Adding extra time to the development cycle will increase your budget and very likely prevent you from delivering the project on time.

Choosing the wrong methodology can also hamper your effective management of the project and may also interfere with the delivery of some of the project's goals and objectives. Software development methodologies are another tool in the development shop's tool inventory, much like your project management best practices are tools in your project manager's tool kit. You wouldn't choose a chainsaw to finish the edges on your kitchen cabinet doors because you know you wouldn't get the results you want. Choose your software methodology carefully to avoid spoiling your project results.

I realize that not every project manager can choose the software methodology they will use on every project. Your organization may have invested heavily in the software methodology and supporting tools used to develop their software. There's not much you can do in this case. Your organization won't look favorably on a request to cast aside a methodology and tools they've spent thousands of dollars on because you recommend a different methodology for your project. We'll give you some tips on how to tailor some of the methodologies to better fit with your project requirements later in this article. In the meantime, before your organization invests in software development methodologies you, or your PMO, ought to be consulted so that at least a majority of projects are benefited from a good fit.

This article won't cover every SDLC out there but we will attempt to cover the most popular ones.

Scrum

Scrum is a name rather than an acronym (which is why I haven't capitalized the letters), although some users have created acronyms, and is commonly used together with agile software development. Scrum is typically chosen because of its iterative nature and its ability to deliver working software quickly. It is chosen to develop new products for those reasons. There is typically no role for a project manager in this methodology, the 3 key roles are: the scrum master (replacing the project manager), the product owner, and the team who design and build the system. There is only one role that you would be asked to play if your organization is committed to using this methodology, scrum master. If you should determine that this would actually be the best methodology for your project, you'll have to re-examine your role as project manager. You can either identify a suitable scrum master and return to the bench, or fill the role of scrum master.

Scrum suits software development projects where its important for the project to deliver working software quickly. Scrum is an iterative methodology and uses cycles called sprints, to build a working system. Requirements are captured in a "backlog" and a set of requirements is chosen with the help of the product manager. Requirements are chosen based on 2 criteria: the requirement takes priority over others left in the backlog and the set of requirements chosen will build a functioning system.

During the sprint, which can last from 2 to 4 weeks maximum, no changes can be made to the requirements in the sprint. This is one of the reasons that a project manager isn't necessary for this methodology. There is no need for requirements management because no changes are allowed to the requirements under development. All changes must occur in the requirements set in the backlog.

Scrum will be suitable for software development projects where the product is a new software product. By new I mean that it is new to the organization undertaking the project, not in general. The methodology was developed to address a need for a method to build software when its necessary to learn on the fly, not all requirements are known to the organization and the focus is on delivering a working prototype quickly to demonstrate capabilities. You need to be careful when choosing requirements to deliver in each sprint to ensure that the set developed builds a software system that is capable of demonstrating the feature set supporting the requirements included.

You also need to ensure that these requirements are well known and understood as no changes are allowed once the sprint starts. This means that any changes to the requirements must come through a new set of requirements in the backlog making changes to these requirements very expensive.

This methodology divides stakeholders into 2 groups: pigs and chickens. The inventors of this methodology chose this analogy based on the story of the pig and the chicken - it goes something like this. A pig and a chicken were walking down the road one morning and happened to notice some poor children who looked like they hadn't eaten for days. The compassionate chicken said to the pig: "Why don't we make those children a breakfast of ham and eggs?" The pig said: "I'm not happy with your suggestion. You're just involved in making the breakfast, I'm totally committed!" The point to this is the product owner, scrum master, and team are all in the "pig" group. All others are in the "chicken" group. You will be in the "chicken" group if you choose the Scrum methodology as a project manager.

Software Testing Removes Bugs and Improves Quality

2011-08-30T03:54:00.000-07:00

Why is software testing so critical? The answer is simple. Software bugs and errors are so widespread and so detrimental that they cost the US economy an estimated 0.6 percent of the gross domestic product. This amount approximately translates into a whopping $100 billion annually. Of this amount, half the costs are borne by the users and the other half by the software developers and software vendors. We must remember that nearly every business and industry in the United States depends on development, marketing, and after-sales support of software services and products. A study conducted by the Department of Commerce's

National Institute of Standards and Technology (NIST) has assessed that more than a third of the costs can be eliminated by improved software investigating infrastructure consisting of a paraphernalia of testing tools for load testing, stress testing, and performance testing.

Many are not aware what software testing is all about. Countless people believe testing of software is high-tech jargon beyond easy comprehension. This perception unfortunately is a myth. In this electronic era, we need not be experts to be familiar with the basic concepts of software investigation. Understanding of the key features and advantages of software investigation helps a wide cross section of professionals and businesspersons in their day-to-day business. Here are answers to some basic question on software analysis.

What Is Software Testing?

In a nutshell, software testing is a process to recognize the accuracy, comprehensiveness, security, and quality of the developed software. In fact, it is a technical investigation intended to assess the quality-related information of the product for which it is planned to be used.

Different Web Testing Applications and Their Functions

The checklist of web testing applications is broad constituting many items. Here we shall deal with a few of them.

* Performance testing: A web application should sustain heavy workload, especially during peak times when many users access the same page simultaneously. In addition, the site must be able to handle input data from a large number of users simultaneously. A performance test also includes stress testing where the system is tested beyond its specification limits.
* Security testing: Security testing is done by various methods. One of the methods is by pasting internal URL directly in the browser address bar without logging in to ensure that the page does not open. Additionally, the product should use SSL for security measures. Web directories and files should not be accessible without the download option.

Most importantly, all error messages, login attempts, including security breach attempts, must get registered somewhere on web server.

What Is The Road Map To Higher Quality Software?

Software testing is a continually evolving process. Software investigating and evaluating companies are consistently striving to identify and remove software bugs. If all software bugs could be identified and removed in real time, the benefits to industry and business are huge and unquantifiable. Plenty of inadequacies are still plaguing the software market. Standardized testing tools must ensure a rigorous testing certification process. The road map to higher quality software is undoubtedly improved and foolproof software testing.

Software Architecture Principles

2011-08-29T07:43:00.000-07:00

welcome to following are the architecture principles I tend to stick to when software architecting solutions:

KISS (Keep it Simple and Stupid) - First cardinal rule I always follow is to keep the architecture simple. I make sure that I do not use jargons or abbreviations that require Googling every 2nd word. I create multiple views of the architecture for different stakeholders (IT, Business, Implementation Team, Infra Team and so on) to convey the design and architecture

Buy vs Build Decision - I generally in favor of buying the functionality instead of trying to re-invent the wheel. I recommend not falling in the trap of "not invented here" syndrome to start creating everything in-house. Requirement Mapping - When using COTS (Commercial Off The Shelf) products in your design, make sure you have mapped your requirements to the product features. Use a COTS product only, if it fulfill 70-80% of the requirements out of box

Identify Integration Points - When you are dealing with multiple COTS products, it is very important to identify the integration points for those products. If you even an iota of doubt, do a proof of concept to validate the same. Do not go by the product brochures, or sales talk. There is nothing like knowing what works and what does not early in the game

Decision Making - In any architecture design, decisions need to be made. Usually people do not want to stick their neck out. I believe in taking decisions based on the information and data available and moving ahead. I might be wrong but at least we move ahead. If the decision was wrong, we correct it on the way. I do not believe in wasting time in endless meetings that do not lead anywhere. I also make a point to validate my decisions by doing proof of concepts to validate some of the technical design issues

Stakeholders - In any solution design, make sure you are aware of your stakeholders. The stakeholders might be direct like Business, Development Team or may be indirect like IT Team, Infra Team, Hosting vendors and Maintenance team. Make sure you share and get feedback from stakeholders on your architecture to avoid any unpleasant surprises later on

Prepare for change - We might always want the requirements to be cast in stone, but seldom they are. To tackle the uncertainty, I try to view requirements as what can potentially change vs what will not change. Design for requirements that are not likely to change (e.g. logging, auditing, persistence mechanism, messaging etc). For the requirements that keep changing (e.g. HTML look and feel, content layout etc) be prepared with a design that is fluid and ready to accommodate changes. If you are aware of areas of change and are expecting changes in that area's, it will be easy to accommodate them

Communication - Communication of architecture to the entire stakeholder team is very important. The stakeholder's include both internal and external teams. On the client side you will have Business, IT, Infra, Security, Enterprise teams. On the other side, you will have your own PMO, Development team, testing team, deployment

Be prepared for surprises - Whatever you do, you still need to be prepared for surprises. Make sure you plan for the same. I have not done a single solution where you do not come across at least one surprise
Enjoy - in the end, do not get bogged down. Enjoy the work. People will appreciate the same!

Agile Methodology Helps in Software Development

2011-08-22T07:13:00.000-07:00

Requirements are an essential part of a software product, and success of a product largely depends on requirements. Requirements-related issues are often named among highest risks of software product development.

The main risks with the requirements are typically connected to missing some requirements, defective or dubious requirements, or requirements that conflict with one another. Working with such requirements leads to wrong product creation, and it will take pretty much time, effort and money to correct mistakes, or even redevelop the product from scratch. This surely sounds really unpleasant. However, the situations like described above, are not rare in the area of software product development.

How can Agile Development methods help?

Agile development methods, when they are suitable for the occasion and implemented correctly can help mitigate those risks. I'm not telling that Agile is the best methodology for software product development ever seen. As any other methodology it has its pros and cons, and there are plenty of Waterfall methods that do great, when they are suitable for the situation. I mean, when the requirements are not finally defined, and there's a high possibility that changes will be introduced, etc., Agile may really help.

As a rule, software development services involve lots of requirements. However, not all of them will be implemented, and most of them will be revised and changed. Changing requirements, in fact, is developers' pet peeve. As Agile Methodology implies iterative approach to software product development, developers analyze and work with requirements defined for this exact iteration.

The customer, commonly involved in iterations planning, is available to discuss and explain questions related to requirements. If there were some misconceptions or controversies, there's a chance for developers to find out what the customer meant by "it should perform... you know... the thing like... well, it should be just great!" It was a joke, but you see my point.

Thus, the required functionality is implemented into the product by small parts, giving both developers and customers clarify clear moments, and giving customers the possibility to introduce changes painlessly for the team involved in their software product development. These are essential parts of software development, and success of a product largely depends on requirements. Requirements-related issues are often named among highest risks faced by a software development company.

Some of the principles behind the Agile Manifesto:
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstance

What Is a Sprint/Iteration in Agile or Scrum Software Development Projects?

2011-08-12T16:53:00.000-07:00

Quite often we get asked by those new to agile project management what exactly an iteration or sprint is? The first thing is that a sprint and an iteration are essentially the same thing, a "sprint" is the term used by scrum, which is the most popular flavour of agile project management. You'll find that most agile practitioners use the terms interchangeably.

A sprint is a "time-boxed" period of work, with a closely defined and agreed output. In the software development world, the output is "potentially shippable" code. At the end of the sprint, the "potentially shippable" code is presented back to the client in a playback session.

By potentially shippable, we mean that it has been built, tested, integrated, documented etc. Any task that is required to be undertaken by the team to release it, needs to be done. It's very rare that a team will "release" each sprint to production, however, highly agile teams may operate in this manner in certain environments.

Another common characteristic of agile development teams are that they are self-managing. Given this trait, it's important that the team themselves agree to what is being asked of them in the sprint and commit to delivering it. In some ways the responsibility of delivery moves from the Project Manger, to the entire team on an agile project.

At the end of each sprint it's important for the team to get together for a retrospective. It's important that everyone attends and it needs to be an open forum to discuss what did and didn't work on the current sprint. As a group you then to come up with a few changes to make during the next sprint. This regular feedback is great and really differs from the traditional "post implementation review" or "post mortem" generally done long after the project is delivered.

So in summary

* A sprint and an iteration are basically the same thing!

* It's a time boxed period of work - generally 2-4 weeks.

* The output is "potentially" shippable software.

* The team themselves must agree on the scope of the sprint.

* The scope is locked-down once the sprint begins.

* To keep improving, each sprint ends with a retrospective.

* A release is generally made up of multiple sprints.

Like article Press +1 for software engineering blog thank!

Agile Development = Change Requirement

2011-08-12T04:15:00.001-07:00

They are the foundation of all agile methodologies and every Scrum team member should be familiar with them.

Here is the second principle, that talks about change:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Traditional development process prefers sticking to their well-thought-out plans that are the result of the requirement-gathering phase. Introducing change late in the development process is costly because you need to repeat the whole waterfall process (analyse, design,...) for each change.

Agile methods take a different approach and treat change as an expected and welcome part of every project. After all, it is all about satisfying the customer because it is necessary to preserve customer's competitive advantage.

During the project the customer can continue to make changes, as long as they prioritize these changes in the appropriate iteration. Product owner is responsible for understanding of the customer needs and grooming the product backlog (prioritizing work based on business value) even near the end of the project. It is even better to make decisions later in the process when we have a better understanding of the product that we are building. Because a product backlog is a living thing that evolve constantly it can respond to the actions of customer's competitors. Agility is all about flexibility and being open to change is a big advantage.

You need to remember the following two words about this principle: welcome (changing requirements) and harness (change)!

Like article Press +1 for software engineering blog thank!

Processes Involved in Software Development Project

2011-07-25T08:18:00.000-07:00

A software development process is a structure to be followed while developing a new software product. There are different types of process models having certain cycles or phases involving various kinds of activities.

Project Kick Off is defined as the initialization of a project. It is an initial plan or proposal describing the main functionality and procedure of a project. Project kick off also narrates the responsibility of the key members in a project, and also describes about the people who are in need of this project.In a nutshell, Project kick off is the method of producing a overall plan for a project at its initiation phase.

Requirement Gathering is usually the first part or segment of a software project. It is the initial stage of product development. In this stage, a thorough market analysis is performed in order to access the real demand of potential customers. Sales and marketing people are mainly involved in requirement gathering stage of a software project. Their analysis helps the developer to develop the software as per the current market demand.

Prototype Development is an important phase in a software development process. The developers first time develop the software as per their conceptual analysis and design with most likely material in this stage. Thus, a through evaluation of design, material, product structure is performed in this stage. Development is a very important stage of software process, where the software is being developed using agile methodology or traditional waterfall method. This step also consists of several sub steps. A traditional waterfall method is based on planning, where as agile methodology works on present feedback.

Software Testing is a pivotal step in any software development project. It determines the quality of software by several industry standard techniques. Software testing is a step to find out the existing bug in newly developed software. There are several testing methods are used named black box testing, white box testing, grey box testing and so on.

Production Roll Out is the next stage where the team of software developers works in full production deployment. In this phase, all of the conceptual designs are tested and modified or refined by implementing in a pilot project. During this phase, testing and other associated supportive activity also have an importance in order to validate the iterative cycles of production deployment.

Knowledge Transfer is another vital aspect of a software process. Knowledge transfer and training go hand by hand in a process. An assessment is needed to conduct among the key workers in a project ensuring their capability while undertaking a particular area of implementation in a software project. A training material is crafted under the guidance of the experts and approved after a through scrutiny. This quality training material is distributed to the key players in the project and the knowledge is transferred as per the project requirement in order to implement the knowledge in different modules of product development.

Post Deployment Software Support is another critical step in a software development process. It is almost essential to provide quality support for the newly implemented software and to trouble shoot the possible problems.

Scrum Methodology with Software Development Works

2011-07-23T23:42:00.000-07:00

Scrum Methodology with Software Development Works

What is scrum methodology? It's a special approach to software development. Instead of a full process, people who use this process work within a framework. So there is a much less formal approach to things in the sense that a very specific plan is excluded in favor of leaving things up to the software development team. And the reason why this is done is because the team will have a better idea of what sort of options are best used for solving a particular type of problem.

This sort of process is in contrast to scrum sprint planning, which is a type of approach that is based around the goal of reaching a specific desired outcome. Instead, the scrum system works through a self-organizing, cross-functional team, which means that the goal is greatly influenced by the team and not necessarily by any specific goal. It also involves putting together feasible ideas and then implementing them. To carry out this process, the entire team will need to assign two positions: a ScrumMaster and a product owner. Although the approach tends to be somewhat less rigid, it still requires a certain level of control and organization.

The ScrumMaster's purpose is to act as a coach, essentially helping each member of the team figure out how they can best contribute to the framework. On the other hand, the product owner represents the target consumer and basically guides the team into creating a product which fits well with the demands of the business as well as its target consumers.

Also, scrum projects do not define progress in terms of a straight line but instead as a series of sprints which are timeboxed iterations for a given period of time, typically a month or a few weeks. At the start of each period, team members will divide the tasks among themselves. The goal is to deliver a particular number of features within a given period of time. Once they have carried out the necessary tasks, the features submitted by each member of the team will then be coded and tested. After that, the team members will then coordinate on how to best integrate these various features onto the system.

After the initial tests and evaluations, the new features are then reviewed by the team, the ScrumMaster and product owner. This is done at the end of the scrum process, and it also includes demonstrations of what the new features can do for the product owner or any other person who is interested in the project.

Like article Press +1 for software engineering blog thank!

Software Development Life Cycle Process For Web Development

2011-07-23T08:53:00.000-07:00

Software Development Life Cycle, commonly known as SDLC, is a predefined set of rules and methodologies opted by web development services. All the phases of the web development are equally important to the process and play the vital role while establishing a profitable development regime. The steps that are measured during the Software design and development are termed as follows:

Requirement Specification and Analysis:

The very primary phase during the execution of web development services called Software Requirements Specification or SRS offers a comprehensive elaboration of the functions and specifications need to be recognized during the software designing and development process. This very first and the foremost step allows to gather information about the overall requirements for the proposed software to be developed. The requirements analysis of the software is categorized further into several objectives to collect information about:

-Resources required for the web development

-Scope of the system

-Purpose of the system

-Limitations of the proposed system
-Web Structure

A very mature and self-explanatory Software Requirements Specification Document is prepared in this stage to cover and enlist all the necessary guidelines to execute the web development services process.

System Design:

Once the requirement analysis phase is done, analysis outcomes are evaluated and scrutinized for the accuracy and efficiency measurement of the proposed web development system. The phase identifies the efficiency objectives taken during the requirement analysis process. The system design process describes the features and specifications in detail. The exhaustive elaboration of the several software design issues include:

-Compact screen layouts

-Defined business rules

-Complete process diagrams of web development services process

-Possible pseudo codes and other required documentation

Coding and System Testing Phase:

Next the phase cones for software coding where the application logic for the software functionalities and user interface are developed. All the coding are written in very strict accordance with the coding standards followed by the industry. The codes are developed in a way to save the system resources and optimize the system efficiency.
- PHP
- JSP

System Deployment:

In the very next phase of deployment at web development company,the final system sets live at the locations, it's meant to be implemented at. The phase decides the shortcomings of the entire software installed and suggests recommendations to accommodate the changes that occurs during the post implementation period.

System Maintenance:

During the system maintenance phase, a number of things about the web application development are taken into the consideration including:

-Changes required in the system

-Correction of any sort

-Some required additions

-Computer platform adjustments
-Promote Website
-SEO

Like article Press +1 for software engineering blog thank!

Software Requirements elicitation ?

2011-07-23T05:58:00.000-07:00

Software Requirements elicitation is the process of identifying the sources of requirements for a new system and obtaining those requirements from those sources.

Software Requirements elicitation is a crucial part of the Requirements Analysis and Documentation Process. Requirements elicitation is a very challenging activity that requires focus and skill from the business analyst.

There are many requirements elicitation techniques that may be used in various situations depending on the level of requirements as well as the type of stakeholder.

Software Requirements Elicitation Techniques Include:

Brainstorming: Brainstorming sessions are used to let the stakeholders come up with creative ideas or new approaches to a problem
Workshops: Workshops are facilitated meetings with multiple stakeholders to draw out and document requirements.
Interviewing: Interviews are in-person meetings where the business analyst asks questions to get information from the stakeholder.
Surveys: Surveys are used to gather information anonymously from the stakeholders.
Documentation Review: This is the process of obtaining requirements from written documentation such as manuals.
Prototyping: This is the use of partially finished versions of the software that have been created to help validate requirements
Focus Groups: Focus Groups are group interviews where the business analyst raises issues and questions to obtain information from the stakeholders.
Observation: Observation is when the business analyst watches the users performing their daily tasks and asks questions about the tasks and work.

A good business analyst should have excellent skills in eliciting good software requirements and using the right elicitation technique for each situation. If you are not familiar with some of these elicitation techniques, consider Business Analyst Training to build up your ability to excel on the job.

Related Article Software Requirement Analysis
1.How to Manage Requirement from Stakeholder
2.Gathering Software Requirement identify the right approve
3.Five tip for Getting Software Requirement
4.Software Requirement Development

Like article Press +1 for software engineering blog thank!

Failure of a project - The Three Main Causes

2011-07-21T06:07:00.001-07:00

Failure of a project - The Three Main Causes

most important factor in the success of an organization is tied to the success of the project. Try to think of it every corporate or organizational improvement initiative, are not these related to the projects? What could be more important, therefore, that ensuring the success of the project?

Taking a survey of different companies in different sectors, it turns out that there are 3 main causes of project failure. If you can then control the triggers of these cases we will be able to significantly increase our chances of success. Hence what are the three main factors that hinder a project along the road to success.

1. The lack of a Project Leader.
And 'in fact surprising how many times you experience this seemingly simple problem. There are many reasons but, in fact, a project team is a group of peers and often no one is assigned or assumes the leadership. Often, no one wants to take that burden because each has his own job and is often overwhelmed by the commitments. Consequently, each company department is often assumed that the other department to conduct the project.
However there is nothing more important in a project and the project leader for many reasons. Some of the most important are: the leader must clearly articulate the objectives of the project should facilitate the development of the project plan with clearly planned tasks, milestones and financial data. The project leaders must proactively deal with obstacles to ensure completion of tasks on time and within budget. In addition, a leader must communicate the progress of the appropriate partners.
A project will not succeed without a leader clearly defined.

2. Lack of clear goals and expectations.
After the non-appointment of a project leader, the lack of definition of expectations and goals is the second major problem. Even the best project leaders can not succeed without clear expectations and equally specific goals. What is the objective of the project? Because this goal is so important to the organization? How each member of the project adds value to get to achieve it? The steps have been taken and the timing?

3. A difficult communication.
A difficult communication can slow down the project even better. Even under the best circumstances it is easy to have a communication wrong and confusing, a bit like the game's wireless phone. In fact, even in company communication that starts from a person and is communicated to a sequence of other people when the final comes from the person is never the same.
Apart from the classic problems of communication there are a whole other set of circumstances that may adversely affect it, since by the barriers of language and cultural barriers to the functional (such as, for example, when sales or communicate with IT talk to the finance research and development). These challenges can be the cause of major obstacles.
Communication is very vital for an organization. Important notices must be repeated several times, must be called in different ways and with different means of communication. We also need to make sure that the members have gotten the message, send reminders, and continue to never interrupt the communication.

what is software development lifecycle

2011-07-16T05:57:00.000-07:00

ment is a fairly long process that includes several phases, such as (a) the requirement (b) design (c) integration (d) test (s) operations and (f) maintenance.

Development of the software cycle describes the various inter-relationships that now have become a rule followed in custom software programming environments. This lifecycle includes:
The waterfall method: This is by far the most rigorous of all cycles of custom software programming life. However, it is well suited for projects that follow a well-defined hierarchy have a strong structural performance requirements. It 'also the method chosen for the services of custom software development where developers are already well aware of the requirements of the software, which will not change drastically in the course of its development.

The Extreme Programming Method is the latest manifestation of the waterfall model, thus making the current fashion of developers working on custom software programming. Given the fact that it keeps a nice pair of eccentricity of the waterfall model too does not work so well for the development of software projects that have moved or complex requirements.extreme programming (XP) model fundamentally believes in starting the encoding as soon as possible without creating a real prototype of the software, which can be shown to the customer for approval.

Throwaway prototyping: supported by Brooks, the model of prototyping to lose for the development of software is useful in situations when the client was able to clearly define its requirements. Software development services follows this approach by building prototypes and functional part of the system giving the customer the freedom to work on this software is incomplete, locate the gray areas that can then compiled by programmers.

Most professional programmers prefer to use the software life cycle, because it helps them avoid the problems of a 'wild hacker' or a 'government bureaucrat', in order to help developers follow a flexible half .

Gantt Chart How to plan and manage a process

2011-07-12T04:10:00.000-07:00

Gantt Chart How to plan and manage a process

The Gantt chart is a tool used to plan the timing of completion of a project, their everyday activities, a year of work, etc.., And to verify ongoing compliance with them. In the Gantt chart the various activities are, therefore, ordered according to a precise temporal progression.

Quick Step to Draw Gantt Chart

One of the most familiar ways of visualising the results of Critical Path Analysis (the project schedule) is on a Gantt Chart. Many project management software applications are based solely on this graphical representation which shows tasks as bars plotted onto a calendar. Dependencies between tasks are shown as arrowed lines.

the Gantt chart is just one of the tools available to you for planning and scheduling your projects. You can:
add tasks, singly or in a list: with list entry you can choose to link the tasks together automatically (finish-start links)

1.draw links for Gantt Chart (sequences and dependencies) between tasks (although the 4c precedence network is a more usable tool for this purpose);
2.extend Gantt Chart the task bar to the required duration;
3.drag the task bar to the desired target dates;
4.delete links and tasks for Gantt Chart ;
5.optionally display different bar colours according to the Team which "owns" the task for Gantt Chart ;
6.optionally display task float (the amount a task can be moved without affecting the schedules of dependent tasks) and baseline durations/dates. Both float and baselines, as well as milestone tasks, are shown in the picture below.

The construction of the Gantt chart goes through four different steps, of which the first three constitute the work plan, while the fourth results in the test plan: will determine all the activities necessary to achieve the objectives (statement of activities), referring, if built, the tree diagram. It may happen that, in some cases, it is not so easy to proceed with the necessary progressive linearity.

In this case, you may take the opposite approach, namely the definition of the goal we proceed in reverse;
it establishes a time limit of the project;
is drawn on the graph the time limit for each activity;
occurs the actual time spent for each activity.

Beside each activity is also a box where you must specify the entity in charge of implementing the activities directly.

In order to plan and optimize the verification activities, it is appropriate, then, explain the scheduling of meetings occur, which can be placed at the moments of the process / line of business are considered particularly significant.

As at the end, it is a good idea to write a book on board, which contains the information notices relating to the progress of operations and the results of checks carried out. If, then, from the diagram we can deduce what happened in the Book of the edge we also why.

One of the strengths of the Gantt chart is that it forces us to an optimization of resources, allowing for simultaneous display of activities, not only sequentially but in parallel, the subjects involved and the timing of the checks.

Another application of the Gantt chart can be found in preparation of the budget of a given project, and in the reporting phase of the resources, human and temporal employed.
Within an overall plan of organizational development, consisting of several projects, each of these you will have to build its Gantt.

The formulation of the Gantt chart corresponds to the phase of planning (Plan), which follows, therefore, the action phase. It requires a preparation time quite expensive, however, if properly developed, during construction you will get in exchange for a saving of time far greater.

The construction of the Gantt chart, is an intense moment of sharing, accountability, and debate with colleagues and trading of assets and resources, so that might even be a "pretext" to agree and share each other's actions and commitments.

In the private sector it is usual to combine this tool with moments of brefing or preliminary comparison, and de-brefing, or to return the next time brefing

Related Article
1. Gantt Chart Already Dead or Still Alive
2. Gantt Chart

Software development for SMEs: the methodology RUP

2011-07-07T06:50:00.000-07:00

Software development for SMEs: the methodology RUP Agile

From old school developer, started the business in the 90s after graduating in Computer Engineering, was used to follow the methodology RUP (Rational Unified Process), unanimously proposed standard to improve the entire software development activities.

Surely, the change from the "navigation view" Rational methodology was a big step forward, especially working at Siemens where resources were many and had the time to plan the activities of software design.

The RUP methodology, however, have begun to show its limitations in the following years, when, in the late '90s and the years 2000, began to change many perspectives in the design of software applications, with a shift of focus he sees more and more ubiquitous and pervasive as the software.

Any company has begun to introduce software for its activities, starting in the early management to the current CRM (Customer Relationship Management) and ERP (Enterprise Resource Planning). And what an outside observer might naively assume that each border is now been reached and surpassed, because of the widespread use of applications is now more necessary to produce customized or port, in addition to routine maintenance of existing applications.

Well, with these new requirements to the RUP methodology has now come to be increasingly "oversized", more suited to large companies and large projects rather than to SMEs. The typical customer of SMEs, in fact, needs the software needs: little interest that the final product integrates a certain technology or not, the important thing is that it is only easy to use and it works. In this sense, the RUP methodology is cumbersome and proportionate.

From the developers point of view might seem a gap not to use the latest version of a given product, even denouncing such failure to the customer! The key point, however, is that small business and entrepreneurs have a different perspective and, above all pursue different results, with a cost-benefit logic clear and unequivocal.

In 2001, therefore, begin with the publication of the Manifesto agility movement that is now called Agile movement and responds so well to the new demands of software development for small business realities. In simple terms, the methodology is agile software development methodology such as "Just in Time" is the industrial planning.

I still remember one of the first, heated, discussions in which I defended the RUP and a colleague I take it apart piece by piece: it seemed absurd at the time that there might be a way to develop projects that will formalize the group without any of the fundamentals of RUP. One limitation of those who had used for over ten years, the "old ways".

What is Agile Project Management?

2011-07-06T04:09:00.000-07:00

What is Agile Project Management?

In recent years there is much talk of what has become more "heavy" for companies to manage their business in highly "turbulent", characterized by hyper-competition and the need to be more productive, faster, open, innovative, high quality. The changing context has also changed the nature of projects to manage.

The projects, although more and more in their short time duration, are generally more complex and project managers often find themselves operating in highly "chaotic". The market and customers today expect products faster, cheaper and better quality that require constant change.

The rule change as it questions the theoretical basis of management's "traditional," especially those related to the stability of the requirements or conditions of initial project.

In an attempt to help project managers and business organizations in the management of so-called "extreme projects," a pool of consultants and world-renowned scholars has developed a set of software methodologies and techniques evolved from traditional project management. It is the "agile methods" of project management (APM = Agile Project Management). In this article we try to understand the underlying principles.

What is Agile method?

Agile methods (Agile Methodologies or Lightweight) assert themselves in IT, in the mid-90s, as opposed to so-called heavyweight methods. In a time when IT managers are increasingly under pressure to get results - in terms of applications that provide improvements to the bottom line enterprise-the budgets for IT are significantly reduced.

These changes lead to an increased interest in software development with agile methodologies, which promise quick delivery and flexibility, while maintaining quality.

Downstream of the proliferation of agile models, the inventors of these methods have formulated a manifesto for the development of "agile" with the following "commandments":

for example How to do "agile project management"?

People and interaction rather than processes and tools
Software that works rather than exhaustive documentation
Collaboration with the customer rather than contract negotiation
Respond to change rather than follow a predetermined plan
In practice, although it recognizes the importance of the elements in the sentences given to the right, you find most important ones on the left.

What Is Change Management?

2011-07-05T04:21:00.000-07:00

What Is Change Management?

What Is Change Management? The Change Mangement is the set of processes, tools and techniques to manage the human side of change processes, to achieve the required results, and actually create change in individual attitudes, the internal teams and the larger system (The Change Management Toolbook).

The first step that we face when we face a work of change management is to understand the "Where are we". Studying then the 'Assessment of the current situation of the processes, methodologies and standards in use, with the critical examination of existing and potential areas for improvement.

The second step is to identify "where we want to" by Identification / definition of the actions needed to improve the efficiency and productivity of the structure and support so as effectively as the company's business processes

In the end we must decide "how we get there." Definition the Project Planning and tools necessary to implement the transition of the Company to the "where", supporting the preparation of the projects launched to improve the training of personnel involved, monitoring progress and results achieved by the projects themselves

But change is always possible? A must is the formula that expresses the concept of

fundamental change: D x V x F> R

D = dissatisfaction. Dissatisfaction with how things are going
V = Vision. Vvisione of what is possible
F = First Steps. Primiparous made concrete in the direction announced
R = Resistance. Resistance to Change

The change is only possible when the product of the forces that drive the change is greater than the resistances that oppose it.

To complete the change must therefore ensure that the person involved will encourage the growth of awareness of their own problems and weaknesses. More concretely, this will be studying and communicating trends expressed the same areas of the market (made by competitors or similar bodies), analyzing the internal and external best practices and including both the dominant ideas about the innovative areas related to critical issues identified.

It 'also should identify itself through a deep reflection and open (Strategic Thinking), the possible solutions to achieve better and stance (Strategic Vision). Such actions should be identified and immediate actions are capable of providing immediate and tangible results well interpreted by top management.
The change, however, is never easy. We succeed only those individuals aware of the energy you need to follow it, while being willing to support it through a strong will (strong commitment)

How to Manage requirement from stakeholder ?

2011-07-04T07:12:00.000-07:00

How to Manage requirement from stakeholder?

In the software development cycle. Requirement gathering of the most difficult thing . Okay we come to understand each other better Requirement gathering from stakeholder.

Maintain a line of communication with stakeholders transparent and efficient is important. Sometimes a meeting of thirty minutes to run down in sixty seconds.Stakeholders often have short attention spans, if you do not catch their attention in the first minute or two, begin to check the mail, watching the clock or worse to yawn during the meeting.

Anyone involved in a project work must of course deal with the sponsors and stakeholders.

With this in mind, here are ten tips that might help during the presentations:
Capture their interest: Agenda (an agenda) is always a good idea, but a brief summary of what will be discussed is even better. It also allows stakeholders to prepare in advance a few questions.

Do not assume that they are aware of their role as stakeholders: They can understand the high level view, but will likely need to having to enrich with various details.

Maintain a simple conversation: it is important to clarify the situation in simple terms without overwhelms information. Go straight to the "hard". (However, we must be prepared to go further if they start asking questions.)

Use numbers and Images: PowerPoint is a great tool for presentation to stakeholders. And 'the way they present information to each other. We should adopt it too.

Sometimes you need to use logic: Accept the fact that there may not always be evidence in support of a particular situation. Do not have numbers to support, could make it difficult, in fact a thesis of success. ain these cases may be helpful to use the formula "if ... then ..." that shed light on a situation with logic. But do not expect the same result in terms of stakeholders' response. For them, the numbers will always make the difference.

Waiting is never a good opinion: Do not wait until a problem is obvious. It is often harder to resolve an issue at that point.

Always offer a solution: Never present a problem to the stakeholders without offering a potential solution. You may celebrate itself as its "death." Finding solutions is certainly an integral part of the work of a project manager.

Specify what you require them: If the stakeholders need to have the shares, do not assume that for them is obvious. Summarize in the form of listing the actions to be undertaken and when.

Always say "yes" But we must be sure to let them know so that these "costs".Sponsors and stakeholders do not like very much "no". Best avoided. But we must be good at to understand the cost of their request so they can judge for yourself if that "is" worth it or not.

Do not stop reporting because stakeholders will cease to ask: If stakeholders perceive that you are not doing anything for them will be so indeed. Do not let the credino or we could be cut off.

Regardless of the methodology of work of your company, there are a lot of project management tools available to help manage tasks (activities) and time-line. Some of them will help to increase communication with stakeholders in the organization.Beyond the fact that the PM tool facilitates this kind of communication or not, ignore the importance of the role of project manager is positively dangerous. What can a project manager to ensure that relationships with stakeholders are increasingly positive?

Software Development Success - 5 Essential Elements

2011-07-02T20:11:00.000-07:00

Software Development Success - 5 Essential Elements

Modern languages for the computer with their high-level constructs have come a long way since the days of assembler programming. With the increasing prevalence of people with computer science classes of programming skills are much more extensive than once and also allow people relatively new to the craft of producing professional applications. But to reach the real level of the professional programmer, there are elements that must be put into practice.

1. Integrated Development Environment (IDE): although you can start programming in many languages with a simple text editor, not longer after that the complexity of your code will become unmanageable without help. Modern IDEs like Visual Studio or Eclipse provide some support to the process of writing the code, the set-up wizards help in the activities, the code completion and management of dependencies and more. It 'almost inconceivable, therefore, try to program an application without one of them seriously.

2. Control the source: the tools for source control integrated directly in the IDE allow you to keep track of changes to the various files that make up the project, allowing you to modify your code with the knowledge that you can always go back to a previous version if things do not work as planned. The repositories for source control are invaluable when working in teams or across several machines.

3. Automatic testing: testing is usually a dirty word in the jargon of the developers, but the recent popularity of techniques such as Test Driven Development has sent back the responsibility of testing to those who belong. I like xUnit frameworks make it easier to write automated tests that demonstrate the functionality of your code run and provide the confidence needed not to have inadvertently tampered with the code when you rewrite the parties.

4. Automated Build: build automate the process of development takes a step forward again, producing a complete, packaged every day or, in some cases every time you decide to place some changes to the source code. In general, the test is performed automatically each time it is the build of the code, giving you the confidence that everything will always work well once it is integrated and reducing those that would otherwise be big headaches later when you try to put it all together for installation.

5. Fault management: if you plan on distributing your application to third parties will be quite conscious, they must find a way to keep track of problems that people may have come with your software and the status of any adjustment you had to do. This could not be more complicated to keep a spreadsheet even though there are a multitude of tools available that can help with this work.

One thing that does not have to worry about is the cost of purchasing these tools that will support your development activities, since there are open source software (or free) high quality in all these categories. In many cases these tools have also become the industry standard tools by beating competition from many owners in terms of quality and market share.

Project Control - 5 Reasons To Stop A Project

2011-07-02T08:16:00.000-07:00

Project Control - 5 Reasons To Stop A Project

We all want to complete projects successfully, this is the main reason why we are project managers. But sometimes the right thing to do is to stop a project, but when this occurs is that?

1. The project is too expensive.
It may be that the costs have been estimated correctly from the beginning. It may be that a supplier has greatly increased its prices. Or which has proved to be necessary to work many more resources than expected. Whatever the cause at times it becomes clear that a project is becoming too expensive in terms of money, time or personnel. If the project begins to move in this direction should consider the possibility of stopping and then stop rising costs.

2. It is not good enough.
This is perhaps the most difficult to understand. One of the possible responses to the fear that the project is becoming too expensive it is to try to resize the results. Sometimes this can even work if you cut only the extras and leave vital parts. But if you cut too much and you begin to reduce costs by cutting to the point that the project becomes useless, it's time to stop the project.

3. Competitor I beat you.
If you're working on a project where you create a product for the market, you should always keep an eye on what your competitors do. If you try to be first on the market but come on time to beat a competitor you need to reevaluate your position. The product you are producing will be able to compete with the competition? You instead need to improve the quality? Perhaps that is facing the cost to continue the project at this point makes no sense when compared to possible returns. It might be time to stop the project.

4. A most important project.
If you're doing a project for any business, then you need to make sure that the business will derive a benefit. But for any business the key point is to have the greatest possible return on money invested. Sometimes this may mean that resources that are used on a project must be moved to another project that has a better return. Therefore, the first project must be stopped.

5. Change of Project Plan.
This is the most general of the 5. A business may undergo multiple changes during his life. Sometimes these changes may have to deal with the upheavals of its business plan. Your project can also be excellent with a good financial return as possible, but if the company decided to change the markets in which it operates, you may still be stopped. Ultimately it is the company to decide which projects you want to do.

Software Project Management - All About Agile Methodology

2011-07-01T03:36:00.000-07:00

Agile Methodology, history.
In 2001 a group of experts on methods for managing software projects met to adhere to a common set of guiding principles for software development, thus defining the "Manifesto for Agile Software Development" .

From the point of view of one definition, agile is a conceptual framework centered on iterative and incremental release of software working, customer-driven. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short period of time. With each of these iterations are released, or increments of functional subsets of functionality.

Agile Methodology
There are several methods like Agile, one of the most popular are the extreme programming (XP), lean software development, Crystal, DSDM (Dynamic Systems Development Method), Scrum and FDD (Feature-driven development). Here is a list of the main differences between each method:

Lean: is closer to the customer, have shorter cycles, eliminate waste, decide as late as possible, gives more power to the team.

DSDM: it gives the team decision-making power, often places emphasis on the release of the product, integrating testing throughout the process, promote collaboration and cooperation among stakeholders.

FDD: focuses on the development capabilities, creates models for each area a different domain.
Crystal: highlights the people, uses techniques of other methods, improve communications, adapt the process itself shortening or extending it.

Scrum: maintains a list of the conditions of the priorities were creating a backlog of product, collaborate via the daily standup meetings, iterative storyline shows the product, use the process to correct the retrospective.
XP emphasizes the value of communication, simplicity, feedback and courage, using specific techniques and collaborative practices.

The Rational Unified Process (RUP) is a process framework that is based on iterative and incremental. The RUP can be configured to support an agile process, an implementation is, for example, the Agile Unified Process (AUP). However the agile community often avoids OR as seen as unnecessary and heavy.
It should be noted that all these processes riasalto damage to the human as part of software development. It 'important to understand the motivations behind the agile methodology. Agile fact was born out of frustration due to wanting to apply some of the unnecessary redundancies.

The extreme programming, planned largely by Kent Beck and Ward Cunningham, is probably the most well known agile process. This process is released from the interest of developers in maximizing the time they can devote to writing code, with respect to time where you need to do other things potentially relevant to release. For example, as long as you hold meetings or redaggono documents. This does not mean that XP ignores the non-programmers, in fact.

XP has started to gain popularity in the late 90's, about 10 years after its creation, Kent Beck published a second book on XP that demonstrated considerable refinement of the guiding principles behind the process. Past years, the focus shifted more on the programmers to understand how the mix of these practices and make them work in a larger number of organizations. Today, XP is a reasonably mature process, well understood by many teams who have managed to sustain for a long period of time.

XP has survived to this day even if you do not hear talk much now. In fact, many teams have abandoned as they failed to make it work. Others have used instead and started to apply it in the best possible way, learning how to release software on a weekly basis.

At some point XP will probably start to fade, since other approaches are best taking bends, but will remain the important contribution he has made in terms of specific practical techniques such as test-driven development, refactoring and integration continues.

PRINCE2 - Write Error Proof Business Case

2011-06-30T09:10:00.000-07:00

PRINCE2 - Write Error Proof Business Case

The draft guidelines describe what needs to be done, the project plan as a spike and you're going to do the Business Case provides the reasons why you should do it.

PRINCE2 terminology in the business case is the "driver" of the project. Senior management reviews the business case before allowing the start of the project in progress, or for each next stage. The Business Case is used as a yardstick to measure the progress of the project. Before allowing any changes to the project plan, executives must consider the impact that this change will have on the business case.
In other words, without a business case no project could start.

The Business Case also justifies the investment in time, money and resources in a project outlining what are the benefits that the project will bring.

It consists of 8 main sections:

Reasons
Why is this project necessary?
The reasons for the need to comply with the program and corporate strategy. You will have to do much work to convince a textile manufacturer that an advertising campaign that persuades people to recycle clothes instead of buying last year could be a new project is appropriate for your company. Another way to think about the reasons for the project is to consider what the project will satisfy the need. Customer satisfaction is low? Your profit margins must be improved? You're still using the same PC purchased in 1983?

Options
What are the options available to meet a need identified? Because the option you chose (the project) should be the best among the lot?
Show that you have seriously considered all the possibilities would greatly strengthen the business case. Provide all information available to senior management will maximize the possibility that someone can suggest an improvement. And 'much better to change your project plan now rather than see it fail halfway.

Benefits
Here's where you have to try to persuade your listeners, because it's worth it? Any possible benefit that the project could lead should be considered, both tangible and intangible benefits. You must be sure that only the benefits that you propose are justified.

If your project is aimed at increasing the bottom line, then presents the numbers reveal that the very detailed. If however the main benefit is to improve customer care or efficiency of the staff, then explains how you plan to put it into practice and what benefits will be.

Risks
What are the major threats against the success of your project? Be sincere. Transparency in this step will allow you to earn the confidence of senior management and will demonstrate your realism, foresight and your potential.

Costs
Senior Project managers need to know how much the total cost expected to authorize the project. Therefore justifies every area of expenditure, so that no one has any doubt that the budget you have provided is not accurate enough.

Timing
How much time is required for the project? Details the activities and objectives of each phase and explains why each is necessary for the timeframe you expected.

Estimated investment
Here is where to compare benefits and costs in order to prove once and for all that your project is worth the investment. Before that senior managers can authorize the project should know what to expect in return for money invested.
The estimate of the investment, made detailing the costs and benefits over a specified period of time, is the most direct way to quantify the return on investment.

Evaluation
Consider your own business case from a perspective as objective and neutral as possible. What are the benefits of stronger and more confident that you promised? Why do you need? Why your project is the best way to reach them?

Software Documentation Project - Benefits

2011-06-30T04:14:00.000-07:00

Software Documentation Project - Benefits

During the practice of Agile and Lean processes can not help but give priority to actions which bring an increase in value. When you have to do with the software documentation, many people who have only a superficial knowledge of Agile might think that this methodology will lead to a reduction or even an absence of design documentation.

Instead, this methodology should be more focused on creating important planning. If this means the documentation, then it should add value and be of the appropriate amount. The documentation should not be an end in itself.

While many engineers are reluctant at the thought of the documentation, it can actually lead to real benefits, including:

1. Determine what others need to know.
Try to think of all aspects of project implementation, post-launch support and maintenance to determine what might be necessary for the core team and members of the support team.
If the team dedicated to the implementation is not the same support team, redarre likely you will need specific documentation. Carefully analyze what that others may need a guarantee will give you better spend your time.

2. Determine the appropriate method and style.
Once you understand the content and the type of documentation required, you can try to understand the type and style to use depending on who will read your work.
Documentation should be searchable within a web page as a wiki page or being somewhat more formal. The writing style and method of release should be based on the audience.

3. Determine a process of renovation.
This is actually the hardest part. Keep documentation up to date requires a well-disciplined process. According to our schedule we should plan a project documentation and ensure continuous updating of the time required to perform such activities. Once you've got a certain rhythm with the documentation, it is worth working hard to keep it updated. Stop this activity to resume after a period of inactivity may be very difficult and impossible to recover what left behind.

4. Benefits and consider other possible fields of application.
While in the first 3 points we focused on whether to provide documentation to support a project or communication with others, at this point we can see how the documentation process can also be a planning exercise.

The fact requires a documentation process that covers various aspects of analytical thinking. This in itself can be a very useful exercise. And 'therefore desirable that during this exercise, you identify which are the most important areas of risk and determine which activities are necessary documentation for these areas.

The software documentation is basically a form of documentation, so make good decisions on "what to document," the method, and finally the style documentary about the process itself is very important. Every activity in our projects require very careful consideration, with documentation is the same.

To be effective you must be borne in mind as well as a specific target audience to whom you devote your work.

Project Management - What Are The Project Controls?

2011-06-29T06:18:00.000-07:00

Project Management - What Are The Project Controls?

software engineering are a very useful exercise, they are to photograph the state of a project or a program so that they can identify what is working well and what areas need improvement instead. Project managers, sponsors and project teams are often involved in daily activities that can lead to not recognizing the true status of the project.

The purpose of these controls is to have objective measurements of how the project is performing or the program according to the objectives and how it adheres to company standards and processes.

Why use checks

And 'well known that in almost all areas of business, the cost of correcting an issue is far above the cost of preventing it. Sometimes the threats can not be detected or ignored because the project team believes that to ensure that the project is successful enough to follow the schedule. At a company level, to conduct audits on a number of projects capable of detecting non-compliance issues and the most common and consequently to resolve them in a less onerous. Moreover, this experience makes in the future we can avoid making the same mistakes on the project.

Who should conduct the checks
Usually it is better to perform the checks by inspectors or consultants, which are independent of the internal policies, and that can provide an objective view. The advice from external inspectors are usually welcome. The last thing you need to do during the inspection is to attack the inspector. A good inspector will use a structure like the PMBOK (Project Management Body of Knowledge) and take into account the specific nature of the organization, its project management and its methodologies.

When the checks must be made
There are two different control approaches on the projects:
Make the check when you are unable to identify what needs to be corrected at the project level.
As part of the planned revision of the project, identify problems before they actually occur. These controls ensure that the proactive project start and continue as efficiently as possible, in each case, the responsive controls allow you to bring under a project over budget or schedule.

Both then make their own part in the organization depending on the size and complexity of the project.
What are the warning signs?

Listed below are 5 categories of warning signs that are quite common in organizations that use the controls to appropriately identify problems:

1. Control Project
This concerns in particular the expected costs for the month or the following year. From this type of signal you can estimate what your costs and make decisions about resources to mitigate the loss or to increase your ROI.

2. Compliance
Compliance with the adoption of a consistent approach to the practice of project management organization. It also deals with the act to ensure that the company's organizational methods are adopted and include best practices, increase efficiency and optimize the communication.

3. Validating the Business Case
The projects are done for many reasons, including increased customer satisfaction, improve efficiency or product development. The controller checks the objectives through the project life cycle, and ensures that the project is still converging towards the goal.

4. Risk and revision of Issue
And 'quite common for managers having to make a risk management "mandatory" and leave aside the planning until the project is completed. The control examines the risk management, identifies the 10 worst risks and has been resolved in an appropriate manner. If they have not been resolved, provide recommendations for resolution.

5. The human factor
Project management is a team game. Consequently, project managers should be concerned relations between the various stakeholders of the project, which may enhance or threaten the success of it. Relationships are constantly changing. The design checks shall also cover the capabilities of the team, the commitment of the sponsor, customer satisfaction, and other human factors that may negatively impact on the project.

By taking the time to have their projects audited by independent inspectors organizations can not only avoid the potential risks so they can also confirm that their project managers are key elements to enable the success of the project.

Project Management - An Introduction - Part 2 / 2

2011-06-28T03:53:00.000-07:00

Project Management - An Introduction - Part 2 / 2

The role of project manager is a role of great responsibility. And 'in fact, the project manager to direct, supervise and control the project from start to finish. Project managers should stay out of the mere execution of work. Here are some of the activities to be undertaken instead:

The project manager must define the project, reducing it to a set of manageable tasks, obtain the necessary resources and create the team that can work PERFORM.
The project manager must determine the ultimate goal for the project and motivate your team to complete the project on time.
The project manager must inform all stakeholders on project progress on a regular basis.
The project manager has to verify and monitor the project risks and mitigate them.
No project ever goes exactly as planned, so project managers must learn to adapt and manage change.

A project manager must have a set of skills, including:
Leadership
Management of people (customers, suppliers, managers and project team)
Effective communication
Influence
Negotiation
Conflict Management
Planning
Contract Management
Ability to lead estimates
Problem Solving
Creative Thinking
Managing schedules

Many things can go wrong with the actual project management, these barriers are often called. Here are some examples of possible barriers:
Poor communication
Disagreement
Misunderstanding
Bad weather
Unions
Personality conflicts
Poor management
Inadequate definition of the objectives

A good discipline will not eliminate all risks ee surprises but certainly will provide standard processes and procedures to address and help prevent the following:
Projects finish late, over-budget or not meeting customer expectations.
Inconsistency between the processes and procedures used by project managers that lead someone to encourage rather than another.

Successful projects, despite an unorthodox plan, are achieved through high levels of stress, willpower and a lot of overtime.

Project management is not seen as an added value but rather as a waste of time and money.Unexpected internal or external events that impact on the project.

Related Article
Project Management - An Introduction - Part 1 / 2

Project Management - An Introduction - Part 1 / 2

2011-06-27T09:51:00.000-07:00

Project Management - An Introduction - Part 1 / 2

Project Management as a modern sense began in the 60's, although it has its deeper roots. The need for project management has always been generated by the realization that an organization gets the benefits if you are able to organize the series of activities related to communication and coordination of work undertaken by different departments and business functions.

One of the first and also of the major uses of project management for the sense we know it today was that of the U.S. space program. The government, the military and companies worldwide have adopted this system. But let's see what are the definitions that are given to project management:

Project management has a defined beginning and an end, not a continuous process.
Project management uses various tools to measure results and track the progress of projects and tasks. These include, for example, the work breakdown structure, Gantt charts and PERT.
The projects usually need resources that can be used in very specific moments, in contrast to organizations that are structured for a full-time resource utilization.
Project management reduces risk and increases the chances of success.

In fact, the project management is often represented with a triangle. The three most important factors of project management are in fact the time, cost and purpose, which are commonly called the triple constraint. These in fact form the vertices that determine the quality.

Thus determines the triple constraint:
1. Projects must be issued in time.
2. Projects must meet the costs.
3. Projects must respect the environment.

Recently this approach has turned into a diamond project management, with time, cost, and quality amb that have become the top 4 and the customer's expectations as a central theme. Since customer expectations vary from person to person is always necessary to ask what they are.

A project goes through 6 different stages during their life cycle:
1. Project Definition: Define the objectives and critical success factors for the project.
2. Starting the project: all you need to set up the project before it can go.
3. Project planning: detailed project plan and how the work will be carried out, including costs, time, and resource estimate.
4. Implementation of the project: to do the job to release the product, service or result.
5. Project Monitoring and Control: Ensure that a project could possibly stick to the floor and take the necessary corrective actions.
6. Closing the project: formal acceptance of deliverables.

Related Article
Project Management - An Introduction - Part 2 / 2

Work Breakdown Structure And The Lattice Logic - Project Planning - Part 2 / 2

2011-06-25T22:16:00.000-07:00

Work Breakdown Structure And The Lattice Logic - Project Planning - Part 2 / 2

Lattice Logic
A grid shows the logical sequence of tasks in a project over time. It shows which activities precede or succeed each other logically. Create a sticky start and an end and put them on the board. The post it should be on the left start and end on the right.

Put these post-it notes in a logical sequence from left to right and add them with arrows of entry and exit, some activities may have more than an arrow. All the connecting lines on a network come on the left (beginning) of the box (the post-it) and out of the right (end). The lines can not enter or exit from the bottom down and disconnected lines are not allowed. All activities must be connected to another one, or at the beginning or end of the project. Finally, we must add the time needed for each activity and calculate the lifetime of the project. At this point the result is logical that the network will help you understand the dependencies, the time duration and workflow design. This technique can reveal important information that could otherwise be neglected.

Project Milestones
Look for milestones in your logical network. A milestone might naturally be called whenever a task or series of parallel meet in a point. To control the project is necessary to define a concrete deliverables for each milestone. A concrete deliverable is nothing more than something visible or tangible hand, as the specification of a design, a prototype, report, etc. A software module.

Use a Software Project Management
The information arising from your WBS and network logic can be inserted into a software package like Microsoft Project, @ task, or more advanced, to provide a detailed plan. Should I add the task, the predecessors, the resources and time estimates in the software and once made the software creates charts automatically. But do not expect the software to plan or manage the project, as usual, the software is only a tool.

Project Checklist
Here is a checklist that can help you create a good project plan and managed by a high performance team involved:

Define what needs to be done by using the Work Breakdown Structure.

Determine the best approach to ensure that everything is done in the best way using a logical network.

Establish the responsibilities and work in terms of duration for each team member is required to complete each task.

Calculate how long it takes to complete the project, its critical path and milestones of the schedule using the Lattice Logic.

Calculate and draw as many people are needed and the percentage of work required by each team member for each phase of the project.

Adjust and refine the project plan to level the individual workloads and adjust the number of people needed during the project.

Optimize the trade-offs to release the best results in the shortest time period.

Use the planning process to enhance the involvement and ownership shared by the members of the team.

Related Work Breakdown Article
Work Breakdown Structure And The Lattice Logic - Project Planning - Part 1 / 2

Work Breakdown Structure And The Lattice Logic - Project Planning - Part 1 / 2

2011-06-25T22:02:00.000-07:00

Work Breakdown Structure And The Lattice Logic - Project Planning - Part 1 / 2

The Software projects are not events that just happen, but are planned. The entire project team should develop the plan in fact, should not only be the project manager to do so. This ensures that the team's experience is taken into account and that everyone is fully involved in the project and has mastered the plan. A good project will provide the following items:

a roadmap that each team member will follow and that is made up of clear and well defined milestones;
a realistic time scale of the project;
details of resource requirements;
validation of the estimated costs;
the task of identifying potential delays;
alerts quotes on the issues.
And 'certainly help to use past experience or historical data, acquired in previous projects:
How long did it take to complete?
how much it cost?
what were the problem areas?
what were the areas of success?

Conduct a project without planning is literally insane. Working without knowing where you are going is the prerequisite for the emergence of problems and failure. Conduct a project without a plan is almost like trying to find their way in a city we never visited and did not have at hand a map. "If you fail to plan, you are planning failure "is one of those best known in project management.

In order to identify the individual tasks in a project is very useful to create a work breakdown structure. The WBS is the foundation for detailed project planning. The first step is to bring together the team and create a brainstorming session to come up with all the "deliverables" of the project, ie, tuttile components, releases must be delivered to you to complete the project. The deliverables are also called WBE, Work Breakdown Element (see figure above). At this point, all activities are identified that are necessary for the creation of deliverables. You will find that the tasks and sub tasks of the project, in no particular order. Write them on sticky notes and attack them on a blackboard. Once everyone has thought of all possible tasks, break down tasks into groups under the main areas of activity. Add, edit, remove and reorder the post-it until the WBS is not accurate, complete and logical. The purpose of a WBS is to decompose the project into steps.

Relate Work Breakdown Structure Article
Work Breakdown Structure And The Lattice Logic - Project Planning - Part 2 / 2
Create Work Breakdown Structure

Activity diagrams

2011-06-24T04:05:00.000-07:00

The activity diagrams is a model a process as an activity consisting of a set of nodes connected by arcs. The semantics is described using the formalism of Petri Nets. Serve So to model aspects of the dynamic behavior of a system.

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.

Activity Diagram can model a process or entity through
- Member
- Transitions between states

The context of an activity diagram can be given by:
Use Cases
classes
interfaces
components
collaborations
operations

Analysis of activities:
graphical modeling of the flow of a use case flow modeling across multiple use cases (diagram
Interaction overview) Design activities modeling the details of an operation,modeling of specific algorithms

Activity Diagram Three types of nodes:
Action nodes
Control nodes
Object nodes
Two types of arcs:
Control Flow
object streams
Actions and activities can be enclosed within the pre-and post-conditions

You can group actions through use of partitions (alsonested systems, and external representatives):
Use Cases
classes
components
organizational units
roles

Collaboration Diagrams vs Sequence Diagrams

2011-06-22T04:36:00.000-07:00

Collaboration Diagrams vs Sequence Diagrams

Collaboration Diagrams

Collaboration is UML,Collaboration Diagrams show the interactions between objects participating in a specific situation. It is more or less the same information shown in sequence diagrams, but here the emphasis is put on how interactions take place over time, while collaboration diagrams show close relations between objects and their topology.

In collaboration diagrams messages sent from one object to another are represented by arrows, showing the name, parameters, and the sequence of the message. Collaboration Diagrams are specially adapted to show a particular stream or situation of the program and are one of the best diagram types to quickly demonstrate or explain a process in program logic.

Sequence diagram

A diagram illustrating the interactions between objects, placing them along a timeline. In particular shows the objects participating in the interaction and the sequence of messages exchanged.
In abscissa are the different objects other than in a specific order, while the ordinate we have developed the time scale down.

Unlike a collaboration diagram, a sequence diagram represents the sequences but not the temporal relationships between objects. A sequence diagram can exist in generic form (describes all possible scenarios) or in the form of a request (describes a specific scenario).

The sequence and collaboration diagrams express similar information, but the show in different ways.
Describes the dynamic behavior of the system is preferable for real-time applications and for complex scenarios.

Related Article
Fundamental Use Case Diagram
Fundamental Class Diagram
Class Diagram Symbol
Unified Modeling Language

Fundamental Use case diagrams

2011-06-20T06:02:00.000-07:00

Fundamental Use case diagrams

A use case diagram is a graph that shows the interactions between a user and a use case of a system. It is particularly useful during the requirements specification.

The actors are actors, external to the system that interact with the system via messages (requests, notices, responses).

The system is 'the entity' whose use is described by all the use cases. More 'specifically, a complete set of use cases describing the use of a complete system from outside, ie from the perspective of the actors who interact with it, without revealing the internal structure of the system.

Each use case describes a complete use of the system, and not 'in UML and then allowed the possibility' that different use cases have an association of communication between them. It's not 'allowed, in other words, the division of functionality' complete separate use cases, to be followed in sequence with each other as steps of a procedure.

The overall effect of the use of associations between use cases and 'still that of a fragmentation of the single use case, although based sull'emersione of particularity' (specialization and extend) or common behaviors (included), instead of 'function on the division of a' complete a sequence of steps or parts, as happens in the functional decomposition of a typical top-down structured approach.

The three associations are allowed:

Generalization / Specialization
Associates a general type of use case to one or more 'specialized use cases. Each use case inherits the specialized features, steps, any points of intersection and the associations of general use case. The specialized use case can 'add new steps, steps, or redefine inherited from the general (override).

Includes
Different use cases have in common a sequence of steps to be performed. In this case, and 'can single out the common sequence, and define it as a use case if' own, from "include" in the use cases originate. So 'show is making the common areas, and avoid repetition in the descriptions of use cases.

Extend
The association "extend" is used to define a use case "base" can 'be "extended" with the behavior defined in another use case, said extension. The extension covers an optional behavior of the base use case, and is' subject to a condition of activation.

The use case extension also defines the condition for its activation. If the condition is checked, the behavior of the extending use case will be 'activated in the appropriate extension points, otherwise not.

Related Article
Fundamental Class Diagram
Unified Modeling Language

Class diagrams Symbols

2011-06-19T00:10:00.000-07:00

Class diagrams Symbols

A class diagram is a graph that describes the types of objects in a static system and the various relationships between them.

Describes:
The name of the class. The attributes of the class diagram specifying the type, visibility 'and any initialization. The visibility 'and' indicated by the symbols + (public), # (pretected), and - (Private).
Operations (methods) contained in the class and their signatures. The visibility 'and' indicated by the symbols + (public), # (pretected), and - (Private).Italicize the names of abstract classes and their abstract methods.

The Association ("Association") declares a semantic relationship between classifiers, and represents a set of links ("links") between instances of these classifiers.

The multiplicity 'indicates the number of instances of the classifier associated to an extreme that can be connected to each of the instances of the classifier placed at the other end of the association, and it' expressed as a range of non-negative integers.

The indicator navigability 'means if and' can reach the instances placed at one end from a resort located at the other end of the association.

The aggregation expresses a relationship between a set and parts of that whole (whole / part), but do not imply special constraints on the demand of all or part of. Opposite composition.

The composition (composition) implies specific constraints:
each instance of the classifier "part" can 'be referred to a single instance of the "whole", in addition the "whole" and' responsible for the creation and destruction of its "parts" that can not have an independent existence. Synonym: composite aggregation.

The dependence (dependency) and 'a semantic relationship between model elements. Indicates that the operation of an element (eg a component) requires the presence of one or more 'items (such as another component). Dependence implies that if an item is modified, you might also need to change any element that depends on it. The dependence connects the elements of the model, and it does not 'require the existence of instances.

The generalization (or Generalization inharitance) and 'a relationship that links an element more' generic to an element more 'specific, ie' describes the inheritance relationship 'between the various classes of a project. The most 'specific needs to be fully consistent with the more' generic, ie 'it inherits all the features, but can' define additional attributes, operations and relationships.
The generalization and 'a report identifying the subtypes: an instance of the generic can' always be replaced by an instance of the more 'special.

Related Class Diagram Article
Fundamental Class Diagram
Unified Modeling Language

Fundamental Class diagrams

2011-06-18T08:44:00.000-07:00

Fundamental Class diagrams

This short post is not intended as a comprehensive and exhaustive discussion about the topic but only and exclusively a note worthy of depth, because there are tons of books covering the subject so certainly can do better than any website .

These diagram types are one of the fundamental Class diagrams UML and allow to describe entity types with their characteristics and possible relationship.

The unit of measurement of the class diagram is the class which represents a category of entities (instances) these objects and is accompanied by a set of attributes (which describe the characteristics of objects derived from class) and characteristics that describe the operations behavior.

A typical class consists of the following

As you can see from the class above, and next to methods or attributes is a symbol, that symbol has a specific meaning and refers to the visibility of the same:

+ = Public: You can access the method / attribute from outside the class

- = Private: you can access the method / attribute only within the class

# = Protected: the method / attribute is inherited by all derived classes

class diagram Associations

Two classes may be linked by associations that represent the bonds; related information about the variety can be made explicit.

class diagram Dependencies

Two classes may be linked by a relationship of independence, which essentially means that the definition of one of the two refers to the other.

class diagram Generalization

Two classes may be linked by a relationship of generalization, which indicates that one of the two classes is considered a generalization of the other.

Relate Class Diagram Article
Class Diagram Symbol

Courage, a value nell'extreme programming

2011-06-17T04:43:00.000-07:00

Courage, a value nell'extreme programming

Many practices extreme programming have to do with courage.

The word "courage" should not be read with reference to the dismissive attitude of the danger from members of the development team - but you start writing code, then we'll see! - But rather the absence of fear.

"But I'm not afraid when I plan!" Many of you are thinking right now. Well, I'm ready to disprove a lot, I will simply ask a single question:

Ok. You that you look around casually Stop it there: you have the answer written on his face. You people who know your code, of which there escapes a single line, so you know that change behavior by changing the speed of thought (sic) and would like to know how can it ever happen that a developer issue its gentle, dear, complex and very private creature ... well ... you are the genes that, for obvious superiority, are not in the scope of this article and agile project management in general. You who have already applied some other agile methodology Scrum or maybe you are already quiet, but ... everyone else, I know: the answer is that you do not feel at all safe!

This lack of peace of mind that you have just imagined - and perhaps also recalled past situations - is the lack of courage which I refer in this article.

Extreme programming attempts to engage the traditional fear of change directly in relation to its origins, with a series of practices designed to encourage developers to do so without fear - and when necessary - changes to the system on which they work to improve the architecture, the scalability and maintainability.

The practice of test driven development and refactoring the developer instill the courage to make such changes incrementally as they are required, well supported by a solid safety net established by the unit tests and acceptance testing.

The customer, on the other hand, not meeting the typical resistance to change that characterizes the traditional development team, he has a chance to live his role with courage, removing the fear of asking for modifications. New requirements may come for a change in the market, for the analysis undertaken by the developers as well, why not, for the simple fact that there is a new good idea that was not there before.

The requirements in software projects change, period. Groped to work in opposition to this fact means trying to design a plane, hoping that the Law of Gravity give us breaks allowing us to fly from Bergamo to Lyon! Being good developers and good project manager does not mean hiding our heads in the sand and give answers to a reality that does not exist, but responding to reality protecting them with tools and techniques that lead to the development of life with serenity and courage ... allowing you to receive the change!

Related Extreme programming article
1.Scrum vs Extreme programming

Agile Development and User-Centered Design

2011-06-16T07:41:00.000-07:00

The subject of the title, that is like Agile development and User-Centered Design, was recently the focus of my interests. After reading countless articles on blogs , I went to investigate, the specialization course Agile Development and Usability.The following are the conclusions I have reached, in the light of my experiences, which are usually with projects lasting up to two or three months and only in the web.

For those who know nothing of Agile development, I will limit myself to a brief description of the most important. Agile is a development process that replaces the traditional waterfall lifecycle in software production. In a nutshell, Agile breaks off in more cycles than it usually is done in a single cycle. Then the phases of Analysis, Planning, Programming and QA Testing and release are carried out only for a small group of features and repeated cycles that follow, smaller groups of other features.Each of these steps, almost always incremental in character, is, in the terminology Agile (SCRUM method), called sprints.
The development was created as part of the Agile software production and this, in my opinion, makes it susceptible of adaptations to be profitably used in the web.Moreover, the underlying principles of agility Manifesto published in 2001, I point out what I think is the most important, by replacing software with user experience: "Our Highest Priority Is To Satisfy the customer through early and continuous delivery of valuable experience." This, I might add, with the aim of allowing the developer to achieve its objectives, informative or commercial.

We come to my vision of how to marry Agile development and UCD. I will do that by dividing the process into phases, analyzing the essential ones.

Phase A - Research and Analysis The phase of research and analysis is critical to the success of a web project. In addition to defining business goals and objectives of the website, planning the research to acquire information about its users, potential or real. For this purpose, interviews are carried out within the company, analyzing the competition, you look at the web site already online (log analysis) and performing ethnographic research (of any kind, informal interviews fairs tests usability in the field). After these activities the client must absolutely approve a document which shows the objectives of the project.

Phase B - Sprint 0: development of the characters, scenes and stories Using the results of research can, in the sprint 0, define the characters and scenarios that will lead us to identify the main stories (another term of Agile Development). One of the critical aspects of Agile development is the management of the priority stories.With the use of characters and scenarios of this aspect is dealt with the upstream segment and therefore the most significant stories about the primary characters.During the sprint 0 the programming team, or at least his representative, must be involved in the development of the characters and scenarios. The client, if involved, will participate in their development and, if involved, will endorse their choice. Also in this sprint will start the procedures for the recruitment of participants in the card sorting and / or participated in the prototyping and / or usability testing, so that they can convene at short notice. Even in this case the characters will be useful for the preparation of the screener.

Phase C - Sprint 1: information architecture, task, wireframes and interface In my opinion, the most important stories of the sprint 1 are those that lead to the development architecture general information, to identify the main tasks, the general design of wireframes and graphic design interface. UCD tools supporting these activities are the card sorting, prototype, owned and cognitive walkthrough with the characters. The possible involvement of people in the design will be useful to collect information to refine and refine the characters and scenarios. In this sprint the programming team will collect information on the state of the art technologies in use in the specific domain (analysis of competing sites) and the definition of technical specifications compatible with the characteristics of the characters. Clearly, the customer will be taken and these decisions will have to share.

Phase D - From the sprint sprint 2 (N): production In the production phase are identified stories that, in turn, lead to the development of certain sections of the website or web application to specific tasks (a registration procedure, for example). In order to be immediately productive, should get the sprint 2 with at least 1 or 2 stories already planned, in order to proceed immediately to the programming phase. Alongside other stories will be designed to be ready at the next sprint. Some asynchronous, therefore, is essential to proceed shipped. UCD activities to verify the choices made are the usability tests (traditional or RITE, Rapid Iterative Testing and Evaluation) with more or less advanced prototypes and cognitive walkthrough with the characters. The issue of a section of the website or one or more features of the web application, the client will assess and provide their feedback. For this reason you should expect some sprints for any adjustments.

Step E - Sprint (N) +1: publication The activities of this sprint are essentially the audit and control. Careful proof-reading, checking the error messages and debug the final product to ensure a higher quality.The website can be published in full or, if the developer so requests, we will proceed with the publication of a significant part, referring to sprint after its completion.

Step F - Sprint optimization and modification If the project involves the sprint you can identify where the research place more suitable for assessing the effectiveness, efficiency and user satisfaction. The most common at this stage is the log analysis, questionnaires and interviews. Clearly, the research will be combined with each sprint a sprint for the implementation of changes.

Conclusions It seems clear, from what I have written to me that development shaped around the Agile User-Centered Design is a well-structured process, which must be driven with a steady hand to meet time and cost. Only in this way to be a lasting and happy marriage.

SOFTWARE VERIFICATION AND VALIDATION PLAN

2011-06-15T06:06:00.000-07:00

All software verification and validation activities must be documented in the Software Verification and Validation Plan (SVVP). The SVVP is divided into seven sections that contain the verification plans for
the SR, AD and DD phases and the unit, integration, system and acceptance test specifications.this figure summarises when and where each software verification and validation activity is documented in the SVVP

Each row of Figure corresponds to a section of the SVVP and each column entry corresponds to a subsection. For example, the entry 'ST Plan' in the SVVP/ST row means that the System Test Plan is drawn up in the SR phase and placed in the SVVP section 'System Tests', subsection 'Test Plan

The SVVP must ensure that the verification activities:
· are appropriate for the degree of criticality of the software ;
· meet the verification and acceptance testing requirements (stated in the SRD) ;
· verify that the product will meet the quality, reliability, maintainability and safety requirements (stated in the SRD);
· are sufficient to assure the quality of the product .
The table of contents for the verification sections is derived from the IEEE Standard for Verification and Validation Plans (ANSI/IEEE Std 1012 -1986). For the test sections it is derived from the IEEE Standard for Software Test Documentation (ANSI/IEEE Std 829-1983 ).

The relationship between test specifications, test plans, test designs, test cases, test procedures and test results may sometimes be a simple hierarchy but usually it will not be. Sections are shown in boxes. Relationships between sections are shown by lines labelled with the verb in the relationship (e.g. 'contains'). The one-to-one relationships are shown by a plain line and one-to-many relationships are shown by the crow's feet

Software verification and validation procedures should be easy to follow, efficient and wherever possible, reusable in later phases. Poor test definition and record keeping can significantly reduce the maintainability of
the software. The key criterion for deciding the level of documentation of testing is repeatability. Tests should be sufficiently documented to allow repetition by different people, yet still yield the same results for the same software. The level of test documentation depends very much upon the software tools
used to support testing. Good testing tools should relieve the developer from much of the effort of documenting tests

Software Verificatio Introduction

2011-06-14T07:29:00.000-07:00

Verification can mean the:

· act of reviewing, inspecting, testing, checking, auditing, or otherwise

establishing and documenting whether items, processes, services or

documents conform to specified requirements

· process of evaluating a system or component to determine whether the

products of a given development phase satisfy the conditions imposed

at the start of the phase

· formal proof of program correctness .

The first definition of verification in the list above is the most general a Validation is, according to its ANSI/IEEE definition, 'the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements'. Validation is, therefore, 'end-to-end' verification.

Verification activities include:

· technical reviews, walkthroughs and software inspections;

· checking that software requirements are traceable to user requirements;

· checking that design components are traceable to software

requirements;

· unit testing;

· integration testing;

· system testing;

· acceptance testing;

· audit

Verification activities may include carrying out formal proofs.

The activities to be conducted in a project are described in the Software Verification and Validation Plan (SVVP).

shows the life cycle verification approach. Software development starts in the top left-hand corner, progresses down the lefthand 'specification' side to the bottom of the 'V' and then onwards up the right-hand 'production' side. The V-formation emphasises the need to verify each output specification against its input specification, and the need to verify the software at each stage of production against its corresponding

specification

2.Software Verifiction and Validation Standard
3.Verification Introduction

software verification and validation standard

2011-06-13T03:38:00.000-07:00

IEEE STANDARDS USED FOR THIS GUIDE
6 standards of the Institute of Electrical and Electronics Engineers (IEEE) have been used to ensure that this guide complies as far as possible with internationally accepted standards for verification and validation terminology and documentation.

Reference Title
610.12-1990 Standard Glossary of Software Engineering Terminology
829-1983 Standard for Software Test Documentation
1008-1987 Standard for Software Unit Testing
1012-1986 Standard for Software Verification and Validation Plans
1028-1988 Standard for Software Reviews and Audits

IEEE Standard 829-1983 was used to define the table of contents for the SVVP sections that document the unit, integration, system and acceptance testing activities (i.e. SVVP/UT, SVVP/IT, SVVP/ST, SVVP/AT).

IEEE Standard 1008-1987 provides a detailed specification of the unit testing process. Readers who require further information on the unit testing should consult this standard.

IEEE Standard 1012-1986 was used to define the table of contents for the SVVP sections that document the non-testing verification and validation activities (i.e. SVVP/SR, SVVP/AD, SVVP/DD).

IEEE Standard 1028-1988 was used to define the technical review, walkthrough, inspection and audit processes. Because of the need to integrate the requirements of six standards into a single approach to software verification and validation, users of this guide should not claim complete compliance with any one of the IEEE standards.

2.Software Verifiction and Validation Standard
3.Verification Introduction

Software Verification and Validation

2011-06-12T00:25:00.000-07:00

Software verification and validation activities check the software against its specifications. Every project must verify and validate the software it produces. This is done by:

· checking that each software item meets specified requirements

· checking each software item before it is used as an input to another activity

· ensuring that checks on each software item are done, as far as possible, by someone other than the author

· ensuring that the amount of verification and validation effort is adequate to show each software item is suitable for operational use. Project management is responsible for organising software verification and validation activities, the definition of software verification and validation roles (e.g. review team leaders), and the allocation of staff to those roles.

Verification focuses on the correctness of the system, its outputs and consistency in the context of the designers’ understanding of the requirements specifications, function and performance tests are best for verification testing. The function test takes the integrated system and checks that it performs all functions described in the functional requirements properly. The performance test checks the system against the nonfunctional requirements, that the system is fast enough, secure enough, and reliable enough to satisfy these requirements.

Validation focuses on ensuring the system actually satisfies the users needs and intentions, acceptance and installation tests verify the working system meets these requirements. The acceptance test allows the customer the validate that the system built according to the requirements is actually what they need. The installation test allows the user to test-drive the system in the environment where it will actually be used, further validating that it will work as needed

Whatever the size of project, software verification and validation greatly affects software quality. People are not infallible, and software that has not been verified has little chance of working. Typically, 20 to 50 errors
per 1000 lines of code are found during development, and 1.5 to 4 per 1000 lines of code remain even after system testing

To be Continue Software Verification and Validation Part 2

Related Article
1.What is Software Verification and Validation
2.Software Verifiction and Validation Standard

Software Requirements Specification (SRS) Template

2011-06-10T23:59:00.000-07:00

The Software Requirements Specifications (SRS) document defines the requirements for a system and the methods to be used to ensure that each requirement is satisfied. The SRS should encapsulate all the characteristics and features expected of the system including functionality, user interfaces,
performance and attributes. Any constraints to the implementation of the system are also discussed in the SRS. The SRS should exhibit the following properties:

Correct
Unambiguous
Complete
Consistent

Writing and using good software requirements specifications is crucial for the success of a project. It carries the initial vision for a project through to its completion and is a vehicle for correcting the vision along the way.

This template is an annotated outline of a software requirements specification document adapted from the IEEE Recommended Practice for Software Requirements Specifications. The IEEE Recommended Practice for Software Requirements Specifications have been reduced and modified in order to simplify this assignment while still retaining the main components and providing a general idea of writing an SRS document. For your own information, please refer to IEEE Std 8301998 1 for the full IEEE Recommended Practice for Software

Software Requirements Specifications Contents

1. INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Reference Material
1.4 Definitions and Acronyms
1.5 Overview of Document

2. OVERALL DESCRIPTION
2.1 Product Perspective
2.2 Product Functions
2.3 Assumptions and Dependencies

3. SPECIFIC REQUIREMENTS
3.1 External Interface Requirements
3.2 Functional Requirements
3.3 Performance Requirements
3.4 Software System Attributes

4. APPENDICES

Gantt Chart in Two-Dimensional Time

2011-06-10T22:14:00.000-07:00

The Gantt chart depicts the current prediction of how the future is going to unfold, but it
does not adequately tell the history of the project’s efforts to get to that future. This is
because the Gantt chart is really a series of charts, each of which has only one dimension—
time—running from left to right across the page. The vertical dimension does not signify a
continuum, but is simply a means of compiling the schedule of individual albeit
interdependent milestones onto one visual display. It is today's snapshot of how those
milestones relate to each other in the overall schedule, but it does not show very well how
those milestones have influenced each other over time.

It would be valuable to have some way of displaying all of yesterday's schedule snapshots
as well as today's on a single chart. Then one could see at a glance the nature of the trends
for each milestone and how they feed into the trend of the master schedule. This can be done
by reformatting the chart so that a second dimension of time is displayed.

The time axis on a conventional schedule chart isn't real time in the sense of showing the occurrence of actual
events with respect to the passage of time; it is only projected time—the pseudo-temporal
axis along which a manager positions his best guesses of when he will achieve his milestones.
In a chart that not only contains the pseudo-temporal axis but also a second axis corresponding to the actual passage of time, one can see the history of a program's perception of the future—how schedules have been influenced by the course of events, and how they have evolved with time. Presentation of schedules in this new two-dimensional format provides managers an extra dimension of information, enabling them to make better subjective judgments on how realistic the current schedule is, and how it may change in the
face of possible future events.

Related Gantt Chart Article
1.Merits of Gantt Charts
2.Simple Gantt Chart Construction
3.Making Gantt Chart
4.Gantt Chart Technique
5.How to Build Gantt Chart

Merits Of Gantt Charts

2011-06-10T21:19:00.001-07:00

To manage a project and to make sure that all the aspects of the project are progressing in the right manner, it is very important to communicate to each other. Graphical aids such asGantt chart enables the information to be identified easily. Therefore, it is widely used to monitor cost and schedule performance during the initial stage of project planning.

Henry Gantt used this procedure in the early 1900s. Therefore, this procedure got its name after him. The Gantt chart, which is popularly known as the bar chart, is a form of representing events against time. The movement of an activity from one point to another tells the amount of work to be done. More than one activity can be described at the starting or the ending point.

A Gantt chart is mainly used in the project to track the progress of an activity and to define any task, which needs to be performed in order to achieve the objective, such as date scheduling, activity schedule and daily progress and to check if the progress of all the activities is on the right track or not.

The simplicity and the ease of using, editing and understanding the gantt chart has made it very popular among a large section of people. With the help of the chart, you can monitor the progress of any activity occurring in the entire course of the project and check where the process is lacking so that the issue can be rectified in order to keep the project on the right track and make sure that the project completes at the right time.

Different Software Development Methodology in Practice

2011-05-31T03:37:00.000-07:00

In the software development field, you will come across a variety of development methodologies followed while developing any software project. This Software methodology refers to processes used to plan the strategies for software development. A software methodology used in one project may or may not be suited to another project. Each software methodology may have its own strengths and drawbacks. There are a variety of software approaches developed over time, which are well-matched to specific kind of projects. Read on to learn a few points on the various methodologies developed.

Waterfall Method: In waterfall method, which is the oldest software development methodology the software development stages are performed in a sequential manner to ensure the quality and reliability of the software. Even though this model provides complete documentation, over quality software and also the work is being done in stages, the waterfall methodology is cumbersome and slow in approach. The basic principles applied here is that the project is divided into different phases, which are sequential in nature. There is stress given on planning and implementation of the overall system and a firm control is maintained on the overall life of the project.

Prototyping Method: Software prototyping refers to creation of incomplete models of the software program during the process which may be different from the final product. Prototyping helps the software users to evaluate the software during the design stage before actually trying them out. In this model, the users are thoroughly involved in the software development process, which increases their acceptance of the final implementation. It also helps the users to understand the business problem, which is necessary to avoid solving the wrong problem.

Rapid application development: Rapid application development (RAD) refers to speedy development and delivery of best quality results at a relatively low investment cost. Rapid application development is a software development methodology that involves nominal planning, thus the software can be written in much shorter time. RAD takes benefit of preset tools and techniques to streamline the process of building information systems. Rapid Application Development has four important features: methodology, people, management, and tools.Development would be slow, If any one of these ingredients is insufficient.

Spiral Methodology: In this methodology various steps are staged for manifold deliveries. Spiral methodology works on the principle that the team is able to start small and help from the trial and error method.

Incremental Development: Incremental software development methodology involves breaking the project into small section, so as to make the change simplified during the development process.

Extreme Programming: Extreme Programming is based on values of simplicity, admiration, communication, advice, and guts. In this changes are implemented as per the customer's suggestion.

Related Article

1.Rapid Application Development

2.Waterfall Model

3.Prototyping Model

4.Spiral Model

5.Extreme Programming