A project can be defined as a plan or proposal; a scheme or an undertaking requiring concerted effort.
Software's are the programs, routines, and symbolic languages that control the functioning of the hardware and direct its operation. They are instructions for the computer. A series of instructions that performs a particular task is called a" program." The two major categories of software are "system software" and" application software." System software is made up of control programs such as the operating system and database management system (DBMS). Application software is any program that processes data for the user (inventory, payroll, spreadsheet, word processor, etc.). A common misconception is that software is data. It is not. Software tells the hardware how to process the data.
Software can also be defined as written programs or procedures or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory.
Unlike a building, software can't be seen, touched, felt or visualized and it's hard for the layman to get a conceptual grip of its size or cost or how long it might take to build.
Hence software projects can be defined as an undertaking to develop computer programs routines, and symbolic languages that control the functioning of the hardware and direct its operation.
Software creation requires concerted effort from the software development teams. A software project team ideally consists of a team leader, software developers and software testers.
However for a software project to be successful it is essential that the project is completed on time and on budget, with all features and functions originally specified. There are a couple of metrics for project success/failure. Some are binary, some are quantitative, and some are qualitative. Many may be influenced by outside factors.
[...] The abstracts in the following pages are some of the key literature reviewed in this project Methodology of literature review Different sources used in order to collect information or data are - Internet - Magazines and Journals - Publications - Articles This encompasses different facets of information sources concerning the identification of various reasons behind software project time overruns. It started with search in Computer and IT magazines, textbooks and lot of other relevant magazines and journals. Information on software project time overruns was mostly available on the websites; lots of articles and presentations on the web sites were analyzed and used in the research for better understanding of the topic. [...]
[...] With 85, Itamarati, while not as assured as Hyatt, started with a high success probability Findings from literature review The literature review has been very informative as it has thrown light on the research and articles that have been written on software project time overruns. Moreover it has helped in identifying the degree of research that has been already done on the subject.It has narrowed the scope of repetition and has formed the basis of secondary data for this study. [...]
[...] It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure. Scope of the Study The respondents to the Standish Group survey were IT executive managers. The sample includes large, medium, and small companies across major industry segments: banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 36respondents representing 8,380 applications. In addition, The Standish Group conducted focus groups and personal interviews to provide qualitative context for the survey results. [...]
[...] Time is the enemy of all projects, and since scope affects time, or project duration, they are linked. Clearly then, minimizing scope increases a project' s chances of success. Minimized scope has replaced small milestones. While these two factors are similar, the act of minimizing scope leads to greater success than does creating small milestones. Concentrating on the top five will result in 70 success points Standard software infrastructures Requirements are in a state of constant flux, but infrastructure needs stability. [...]
[...] Each factor is measured over a scale of four: Certainly Responsible, Responsible to a Great Extent, Responsible to Some Extent and Not Responsible Lack of user input Interpretation 37% of the respondents feel that lack of user input is to some extent responsible for project time overrun while 36% feel that this factor is certainly responsible. Only feel that lack of user input is not responsible for project time over run Incomplete requirements and specifications Interpretation This factor is considered by the majority of the respondents i.e of the total, as certainly responsible for project time overruns followed by 31% of respondents who feel that this factor is responsible to a great extent for project time overrun and voted for responsible to some extent and not responsible respectively. [...]
APA Style reference
For your bibliographyOnline reading
with our online readerContent validated
by our reading committee