Software Doubts And Ideas For Projects

Software Doubts and Ideas Explaining 

Software Myths 

There are some misbelieves in the software industry about the software and process of building

software.  For any software developer it is a must to know such beliefs and reality about them. 

Here are some typical myths :

1.     Myth : Using a collection of standards and procedures one can build software.

(Management Myth)

Reality: Eventhough we have all
standards and procedures with us for helping the developer to build software, it is not possible for software professionals to build desired product.  This is because – the collection which we have should be complete, it should reflect modern techniques and more importantly it should be adaptable.  It should also help the software professional to bring quality in the product.

2.     Myth : Add more people to meet deadline of the project

(Management Myth)

Reality : Adding more people in order to catch the schedule will cause the reverse effect on the software product i.e., software project will get delayed.   Because, we have to spend more time on educating people or informing them about the project. 

3.     Myth : If a project is outsourced to a third party then all the worries of software building are over.

(Management Myth)

Reality : When a company needs to outsource the project then it simply indicates that the company does not know how to manage the projects.  Sometimes, the outsourced projects require proper support for development.

4.     Myth : Even if the software requirements are changing continuously it is possible to accommodate these changes in the software.

(Customer Myth)

Reality : It is true that software is a flexible entity but if continuous changes in the requirements have to be incorporated then there are chances of introducing more and more errors in the software.  Similarly, the additional resources and more design modification may be demanded by the software.

5.     Myth : We can start writing the program by using general problem statements only.  Later on using problem description we can add up the required functionalities in the program.

(Customer Myth)

Reality : it is not possible each time to have comprehensive problem statement.  We have to start with general problem statements, however by proper communication with customer the software professionals can gather useful information.  The most important thing is that the problem statement should be unambiguous to begin with.

6.     Myth : Once the Program is running then its over !

(Practitioner’s Myth)

Reality : Even though we obtain that the program is running major part of work is after delivering it to customer. 

7.     Myth : Working program is the only work product for the software project.

(Practitioner’s Myth)

Reality : The working program / software is the major component of any software project but along with it there are many other elements that should be present in the software project such as documentation of software, guideline for software support.

8.     Myth : There is no need of documenting the software project; it unnecessarily slows down the
development process.

(Practitioner’s Myth) 

Reality : Documenting the software project helps in establishing ease in use of software.  It helps in creating better quality.  Hence documentation is not wastage of time but it is a must for any software project.

Risk Identification in Software Project

What is Risk Identification ?

Risk identification can be defined as the efforts taken to specify treats to the project plan.  Risk identification can be done by identifying the known and predictable risks.

The risk identification is based on two approaches

1. Generic Risk Identification – It includes potential threat identification to software project.
2. Product Risk Identification – It includes product specific threat identification by understanding people, technology and working environment in which the product gets built.

Normally the risk identification is done by the project manager who follows following steps :-

Steps 1 : Preparation of risk items check list

The risk items can be identified using following known and predictable components.

1. Project Size– The risk items based on overall size of the software product is identified.
2. Business impact – Risk items related to the marketplace or management can be predicted.
3. Customer Characteristics – Risks associated with customer-developer communication can be identified.
4. Process definition – Risks that get raised with the definition of software process.  This category exposes important risks items because whichever is the process definition made, is then followed by the whole team.
5. Development environment – The risks associated with the technology and tool being used for developing the product.
6. Staff Size and experience – Once the technology and total related risks items are identified it is essential to identify the risk associated with sufficient highly experienced and skilled staff who will do the development.
7. Technology to be built – complexity of the system should be understood and related risk items needs to be identified.

After preparing a risk item checklist a questionnaire is prepared.  These set of questions should be answered and based on these answers the impact or seriousness of particular risk item can be judged.

Step 2 : Creating Risk Components and drivers list.

The set of risk components and drivers list is prepared along with their probability of  occurrence.  Then their impact on the project can be analysed.

Risk Components and Drivers

The Types of Risk Components :

1. Performance Risk,


2. Cost Risk,


3. Support Risk,


4. Schedule Risk.

How to Access Overall Project Risk ?

The best approach is to prepare a set of questions that can be answered by Project managers in order to asses the overall project risks.  The questions can be

1. Will the project get proper support by the customer manager ?
2. Are the end-users committed to the software that has been produced ?
3. Is there a clear understanding of requirements ?
4. Is there an active involvement of the customer in requirement definition ? 
5. Is that the expectations set for the product are realistic ?
6. Is project scope stable ? 
7. Are there team members with required skills ?
8. Are project requirements stable ?
9. Does the technology used for the software is known to the developers ?
10. Is the size of team sufficient to develop the required product ?
11. Is that all the customers know the importance of the product / requirements of the system to be built ?

Thus the number of negative answers to these questions represents the severity of the impact of the risk on overall project.

Preparing a System Design for Project

System Design of a Project

Design Process

Software Design is an iterative process using which the user Requirements can be translated into the software product.

At the initial stage of the software is represented as an abstract view. During the sub-sequence iterations data, functional and behavioral requirements are traced in detail. That means at each iteration the refinement is made to obtain lower level details of the software Product 

Design Concepts

The Software design concept provides a framework for implementing the right software. 

The following are certain issues that are considered while designing the Software : 

• Abstraction, 
• Modularity, 
• Architecture, 
• Refinement, 
• Pattern, 
• Information Hiding, 
• Functional Independence, 
• Refactoring, 
• Design Classes. 

Golden Rules 

Thao Mandel has proposed three golden rules for User Interface Design 

1. Place the User in Control, 
2. Reduce the User's Memory Load, 
3. Make the interface consistent,  

Design is the first stepping stone for the development of any System. 

• Input Design, 
• Output Design, 
• Database Design. 

Interface Analysis 

Before Preceding for Interface Design it is necessary to understand the problem. 

Understanding the Problem means understanding : 

1. The People or User who actually interacts with the system. 
2. The Task that are performed by the end user for interacting the system. 
3. The contents of the interface that will be displayed to the user. 
4. The environment in which the task will be conducted. 

Input Design 

The input design is the link between the information system and the user, it comprises the director specification and procedures for data preparation and those steps that are necessary to put transaction data into a usable form for processing data entry. The activity of putting data in to the computer for processing can be achieved by having people key data directly in to the computer for processing can be achieved by having people key data directly in to the system. The design of inputs, focuses on controlling the amount of inputs required, controlling error, avoiding delay, avoiding extra steps and keeping the Process simple. 

Output Design 

The objective of any information system in the generation of reports. The output provides direct source of information to the user and so it's the most important in the system design phase. It reports to actual output generated by the system. This is major goal in designing a new system. The system generate the following reports during the process. 

Database Design 

Database files are the key source of Information into the system. The final design must satisfy user needs in terms of completeness, integrity, performance and other factors. The main objective of the database design is to store the captured data efficiently and facilitate its timely retrieval.

What is a Software Project and How to Do

What is Project ?

A Project is a Software Product gets developed after following systematic theories, methods and tools along with the appropriate management activities.

For finding the solution to the problem an Engineer applies appropriate theories, methods and tools.  While finding the solutions, engineers must think of the organizational and financial constraints.  Within these constraints only, he / she has to find the solution.

Goals and Objectives of Software

While developing Software Project following are common objectives.

• Satisfy users requirements,
• High Reliability,
• Low Maintenance costs,
• Delivery on Time,
• Low Production Costs,
• High Performance,
• Ease of Reuse.

How Product Done in Software Engineering 

In Software Engineering the systematic and organized approach is adopted. Based on the nature of the problem and development constraints various tools and techniques are applied in order to develop quality software. 

The Definition of Software Engineering is based on two terms : 

1. Discipline 

For finding the solution to the problem an Engineer applies appropriate theories, methods and tools. While finding the solutions, Engineers must think of the organizational and financial constraints. Within these constraints only he / she has to find the solution. 

2. Product 

The Software product gets developed after following systematic theories, methods and tools along with the appropriate management activities. 

Step by Step Process in Software Engineering Project.

The following are the Process.

• Objective of the Software,


• Data Collection,


• Feasibility Study,


• Design,


• Coding,


• Testing,


• Implementation,


• Maintenance.

The Project Can be done in all Departments,

·        Computer Science,

·        Information Technology,

·        Management,

·        Commerce,

·        Mathematics,

·       Statistics,

·        Biology,

·        Engineering,

·        Education,

·        Hotel Management,

·        Catering Science,

·        Visual Communication,

·        Journalism,

·        Agriculture etc.,

The Project Related Article are Updated Here for

§        School Project,

§        College Project,

§        Research Project,

§        Software Project.