Project Scheduling - Different ways for tracking the schedule.

A proper project schedule is very important for a successful project delivery. The project schedule is a road map for a software project manager. A project schedule needs to be properly developed. A proper project schedule defines the tasks and milestones that are tracked and controlled as project proceeds. This tracking needs to be accomplished nicely and there are different methods and ways to do so...

- Timely project meetings regarding the status of the project are held and it should be ensured that each team member should report the progress achieved and the problems that are faced.
- There are different reviews that are conducted throughout the software engineering process. It becomes necessary to evaluate the results of all these reviews in order to accomplish proper tracking.
- To accomplish proper tracking, for each task of the project, the actual start date and the planned start date should be compared.
- To accomplish tracking, one should determine whether the formal project milestones are achieved by the scheduled date.
- To accomplish tracking, progress should be assessed quantitatively.

The best indication of progress is the completion and successful review of a defined software work product.
The control administers the project resources, cope with problems and direct the project staff. Control is light if the project is on schedule and within budget. The control is exercised to reconcile the problems if they occur.

In case the problem is identified and diagnosed:
- staff is redeployed
- additional resources should be focused on problem area.

A severe deadline can be managed by time-boxing technique. It chooses an incremental software paradigm and a schedule is derived for each incremental delivery. This technique is done when the product may not be deliverable by a pre-defined deadline.

Different licensing situations in software development - Part 4

In previous posts (licensing situations in software), I have talked about how not licensing any sort of stuff not owned by you can cause a lot of problems. This can be when you are using software that is not owned by your company (and for which you have not taken the license to use within your software), or when you are using content such as images that does not belong to you. Another great example is when you use quotes / sections from books / parts of poems that do not belong to you (which can happen if you are developing a software that does some sort of word processing / helps in the creative process / have a website that provides some sort of content (such as a site that provides you electronic greeting cards)). All these cases lead you towards violation of somebody else's ownership and possible legal action against you.
If you think that this is not serious, consider the following cases:
Claims by Microsoft (link). These claims are from Microsoft against Open Source software.
Action against Microsoft (link). This was a judgment against Microsoft by a judge for the incorporation of some software.
These are big cases, but there are smaller cases that happen all the time, where companies have to pay damages because they are using some components for which the licensing is not proper. So, you need to ensure that any component that you integrate, or any content owner by others that you integrate, all needs to be thought through and part of a strategy.
Well, this is enough for this post, will write more on this topic in the next post.

Different licensing situations in software development - Part 3

In previous posts (software licensing), I have been writing about software licensing, the need for the same, and what implications this has for the software development process. In this post, I will write more on this topic.
Another area where people slip up is when they need an image for their software. Consider that you are developing a software that is meant for children, and you want a great image for some of the dialogs / screens that are there in the software. Now, what do you do ? Well, I have seen many cases where people look for some great looking images on the internet, find them, reshape them as per their needs, and then start using those images.
In many cases, this strategy works, since the original owner of the image does not that something like this has happened. Or the images used are such that they are somewhat generic, and the owner cannot even figure out that this is their specific image. Or, the person thinks that it is just an image, and the effort involved to challenge the usage of the image in a commercial usage is not worth it.
But there is a contra case. Suppose you just downloaded some images, and these images also show some recognizable faces. This is a very serious matter. When a recognizable person is used in commercial situations, the person should have given permission to use their image for this specific purpose. If this is not done, the person can file suit, and possibly claim penalties for such unauthorized usage. Such usage is typically covered under a term such as a model release (link)

In case you are still not convinced about the need to use the proper software licenses / copyright of images, I will wrote more about this in the next post on this subject.

Software Project Scheduling - Timeline Charts

What is a timeline chart ? Well, a project timeline is created to display the various activities of a project on a chart, in such a way that it depicts the tasks of the projects, the duration of the tasks, the sequencing of these, and the major milestones of the project. A Gantt chart is a typical software timeline chart, and the most popular one that most people tasked with preparing such a chart are aware of.

In timeline charts, a series of events are arranged on a bar graph. These charts are like user items. Each event can be a single point in time or a date range. A timeline chart enables the planner (and other stakeholders) to determine the set of tasks that will need to happen at a given point of time. The effort, duration and start date are inputs for each task. These tasks can be assigned to specific individuals. With these inputs, mapped on a chart, the timeline chart is developed. It is also called Gantt chart and it can be developed for the entire project. When the Gantt chart was first developed, it was a revolutionary construct in the field of project management.

The format of a timeline chart depicts the part of software project schedules that emphasize the concept scoping task for the product on which work is happening. All work tasks are located on the left hand column. The duration of each task is indicated by the horizontal bars. The diamonds indicate the task concurrency which indicates when multiple bars occur at the same time.

Project tables are tabular listing of all project tasks. Project tables are produced when all the information which is necessary for the generation of timeline charts are obtained. These project tables consists of all project tasks, its start and end date and the related information.

How a task network is defined for a software engineering project?

The task network is a useful mechanism for depicting inter task dependencies and determining the critical path. When more people are working on a software engineering project, tasks and sub-tasks have their own inter-dependencies and also as the number of people increases, the development activities and tasks are performed in parallel. These concurrent tasks must be coordinated so that so that they will be complete when later tasks require their work products.

What is a task network?
It is also known as activity network. It is a graphic representation of how the tasks are flowing in a software engineering project. There is a pattern and a sequence that is followed by tasks. This task network can be used as a mechanism or a way to know this sequence and pattern of the tasks that can act as an input to an automated project scheduling tool.

On a macroscopic view, task network depicts the software engineering tasks. On a microscopic view, each and every task in the task network is expanded. For a concept development project, task network includes the following tasks:
- Concept Scoping
- Concept Planning
- Technology and Risk Assessment (It constitutes three tasks).
- Proof of Concept
- Concept Implementation (It constitutes three tasks).
- Integrate the three tasks which constitutes concept implementation.
- Customer Reaction

Software engineering activities are concurrent in nature. This nature leads to scheduling requirements. The project manager should keep in mind the following points to ensure continuous progress:
- He should determine the inter-task dependencies.
- He should be aware of tasks that lie on critical path which means the tasks that should be completed on schedule if project has to completed on schedule.

How to define a task set for a software project?

The process model is defined by a set of tasks which enables the software team to define, develop and support computer software irrespective of whether the software team uses an incremental model, linear sequential method, an evolutionary model. Nearly every project will have a different task set which means that no single task is appropriate for all projects.

The set of tasks that a simple project uses or needs is different from the set of tasks that is needed by a large complex system. A collection of task sets should be defined to meet the needs of different types of projects by the software process that is effective.

The task set that is developed should be distributed on a project time line. Task set depends on the type of the project and the rigor with which the software team decides to do the work. Different kind of projects encountered by software organizations are:

- Application enhancement projects
- Content development projects
- New application development projects
- Application maintenance projects
- Re-engineering projects

The factors that affect the choice of the task set for a single project type are:
- project size.
- number of potential users.
- critical nature of mission.
- longevity of the application.
- requirements stability.
- maturity of applicable technology.
- embedded and non-embedded characteristics.
- performance constraints.
- project staff.
- re-engineering factors.

For example, in concept development projects, major tasks followed are:
- Concept scoping
- Preliminary concept planning
- Technology risk assessment
- Concept proof
- Implementation concept
- Customer reaction

Project Scheduling - Relationship between people and effort

For a small project, requirements analysis, performing design, code generation and test conduction can be done by a single person but as the size of the project increases, more people get added. Adding people later in the project often has a disruptive effect on the project causing schedules to slip even further. If more people are added to a late project, be sure that you have assigned them work that is highly compartmentalized.

The people who are added later in the project should know the system properly. In addition to the time that it takes to learn the system, it also increases the number and complexity of communication paths. Every communication path requires additional effort and time.

Project schedules are elastic. It is possible to compress or extend a desired project completion date to some extent. If delivery can be delayed, the PNR curve indicates that project costs can be reduced substantially. As the project deadline becomes tighter and tighter, you reach a point at which the work cannot be completed on schedule, regardless of the number of people doing the work. The reality should be faced and a new delivery date should be defined.

Effort should also be distributed across the software process workflow. Recommended effort distribution is referred as 40-20-40 rule. Front end analysis and design and back end testing are allocated 40% of all effort while 20% of effort is allocated to coding. The characteristics of each project must dictate the distribution of effort. Requirement analysis may comprise 10-25 percent of project effort. Effort on analysis or prototyping should increase in direct proportion with project size and complexity.