Sunday, 21 July 2019

Software Project Scheduling

Project scheduling is an important step in the software development process, software project managers often uses scheduling to perform preliminary time and resources estimates, general guidance and analysis of project alternatives.

One of the major challenges in software project management is that it is difficult to follow to the schedules due to the uncertainties related to requirements, schedules, personnel, tools, architectures, budgets, etc…

Project scheduling is the process of deciding how the work in a project will be organized as separate tasks, and when and how these tasks will be executed. 

You estimate the calendar time needed to complete each task, the effort required and who will work on the tasks that have been identified. 

You also have to estimate the resources needed to complete each task, such as the disk space required on a server, the time required on specialized hardware, such as a simulator, and what the travel budget will be. 

Project scheduling activities
  1. Split project into tasks and estimate time and resources required to complete each task.
  2. Organize tasks concurrently to make optimal use of workforce.
  3. Minimize task dependencies to avoid delays caused by one task waiting for another to complete.
  4. Dependent on project managers intuition and experience.

The project scheduling process
 In order to schedule project activities, a software manager needs to do the following basic principles.

Compartmentalization: The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are refined.

Interdependency: The interdependency of each compartmentalized activity or task must be determined. Some tasks must occur in sequence, while others can occur in parallel. Some activities cannot commence until the work product produced by another is available.

Time allocation: Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis
Effort validation: Every project has a defined number of people on the software team. As time allocation occurs, you must ensure that no more than the allocated number of people has been scheduled at any given time.

Defined responsibilities: Every task that is scheduled should be assigned to a specific team member.

Defined outcomes: Every task that is scheduled should have a defined outcome.

Defined milestones: Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

The Relationship between People and Effort

In small software development project a single person can analyze requirements, perform design, generate code, and conduct tests. As the size of a project increases, more people must become involved. Adding people later in a project often has a wrong effort on the project, causing schedule to slip even further.

An Empirical equation

We can determine the highly non-liner relationship between chronological time to complete a project and human effort applied to the project. The number of delivered lines of code


Where “L” is the effort and development time, “E” is the development effort in person /month, “P” is the productivity parameter that leads to high quality software engineering work, “t” is the project duration in calendar months.

Effort distribution 

Each of the software project estimation technique leads to estimates of worth units requires completing software development. A recommended distribution of effort across the definition and development phases is often referred to as 40-20-40 rule. Forty percent of all effort is allocated to front end analysis and design. A similar percentage is applied to back-end testing. You can correctly infer that coding (20 percent of effort) is de-emphasized. A range of 20 to 25 percent of effort is normally applied to software design. If software is human rated (i.e., software failure can result in loss of life), even higher percentages are typical.

Saturday, 20 July 2019

Incremental Model in Software Engineering

Incremental process model is also known as successive version model.

First, a simple working system implementing only a few basic features is built and then that is delivered to the customer. Then thereafter many successive iterations/ versions are implemented and delivered to the customer until the desired system is realized.

A, B, C are modules of Software Product that are incrementally developed and delivered.

Each iteration passes through the requirements, design, coding and testing phases. And each subsequent release of the system adds function to the previous release until all designed functionality has been implemented.

The system is put into production when the first increment is delivered. The first increment is often a core product where the basic requirements are addressed, and supplementary features are added in the next increments. Once the core product is analyzed by the client, there is plan development for the next increment.

When to use this

  1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
  2. When Requirements are known up-front.
  3. When Projects having lengthy developments schedules.
  4. Projects with new Technology.


  1. Requires good planning and design.
  2. Total cost is not lower.
  3. Well defined module interfaces are required.

Friday, 19 July 2019

Rapid application development model (RAD)

The Rapid Application Development Model was first proposed by IBM in 1980’s. The critical feature of this model is the use of powerful development tools and techniques.

A software project can be implemented using this model if the project can be broken down into small modules wherein each module can be assigned independently to separate teams. These modules can finally be combined to form the final product.

Development of each module involves the various basic steps as in waterfall model i.e. analyzing, designing, coding and then testing, etc. as shown in the figure.

Another striking feature of this model is a short time span i.e. the time frame for delivery (time-box) is generally 60-90 days.

Following are the various phases of the RAD Model

Business Modeling

In business modeling, the information flow is modeled into various business functions. These functions collect following information
  1. Information that derives the business process
  2. The type of information being generated
  3. The generator of information
  4. The information flow
  5. The process of information.

Data Modeling

In this phase the information obtained in business model is classified into data objects. The characteristics of data objects (attributes) are identified. The relationship between various data object is identified.

Process Modeling

In this phase the data objects are transformed into process. These processes are useful to extract the information from data objects and are responsible for implementing business software.

Application Generation

For creating software various automation tools can be used. RAD also makes use of reusable components of software.

Testing and Turnover 

As RAD uses reusable components the testing efforts are reduced. But if new components are added in software development process then such component need to be tested. It is equally important to test all interfaces.


Find Us On Facebook

C Programming


C++ Tutorial


Java Tutorial


Computer Basics


MS Office


Database Management