×
Start where you are. Use what you have. Do what you can.
--Your friends at LectureNotes
Close

Note for Software Project Management - SPM by kishan chandra

  • Software Project Management - SPM
  • Note
  • RD & DJ College Munger - DJCollege
  • Computer Science Engineering
  • B.Tech
  • 3 Topics
  • 7496 Views
  • 133 Offline Downloads
  • Uploaded 11 months ago
Kishan Chandra
Kishan Chandra
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-3

Tutorials - Software Project Management By Vinod Kumar Principles of Software Management : 1. Freeze the requirement before design. 2. Forbid (to oppose) coding before detailed design review. 3. Use high level programming language. 4. Complete unit testing before integration testing. 5. Maintain detailed traceability among all artifacts. 6. Thoroughly document each stage of design. 7. Access quality with the help of an independent team. 8. Inspect everything. 9. Plan everything with high precision. 10. Rigorously (carefully) control the source code baseline. About 90% of the time, the process obtained as a result of conventional development is late, over budget and expensive to maintain the software system. Unit testing and integration testing consume too much time and effort in developing the software. The success ratio in conventional software development is 10:1. Conventional: 1960-1970, Craftsmanship Organizations used custom tools, custom processes and virtually all custom components built in primitive languages. Project performance was highly predictable. Transition: 1980-1990, Software Engineering Organizations used more-repeatable processes and off-the-shelf tools (COTS: reusable). Mostly (>70%) custom components built in higher level languages and (<30%) were available as commercial products like OS, DBMS, Networking and GUI. Modern practices: 2000 and later, software production. - 70% component-based, - 30% custom Job Versus Projects „Jobs‟ – repetition of very well-defined and well understood tasks with very little uncertainty „Exploration‟ – e.g. finding a cure for cancer, the outcome is very uncertain „Projects‟ – in the middle!

Text from page-4

Tutorials - Software Project Management By Vinod Kumar Another key aspect of a project is that the undertaking in non-routine: A job which is repeated a number of times is not a project. There is a hazy boundary in between. The first time you do a routine task, it will be very like a project. On the other hand, a project to develop a system that is very similar to previous ones that you have developed will have a large element of the routine. Characteristics of Projects A task is more „project-like‟ if it is: Non-routine Planned - Non-routine tasks are involved - Planning is required the project has a predetermined time spam Aiming at a specific target - Specific objectives are to be met or a specified product is to created Work carried out for a customer - Work is carried out for someone other than you Involving several specialisms - Work involves several specialisms Made up of several different phases - Work is carried out in several phases Constrained by time and resources - The resources that are available for use on the project are constrained Large and/or complex - The project is large or complex Project Size Categories Trivial projects :One programmer few days/weeks 10 to 20 subroutines Small projects :One programmer 1000-2000 lines <500 statements 1 to 6 months 25 to 50 routines Medium size projects :2-5 programmers 1-2 years 10,000-50,000 source code 250 to 1000 routines include assemblers, compilers, process control applications, inventory systems, small management information systems. Large projects :5-10 programmers 2-3 years 50,000-1,00,000 source code include large compilers, small time-sharing systems, database, real time control system Very large projects :100-1000 programmers 4 to 5 years 1 million source instructions

Text from page-5

Tutorials - Software Project Management By Vinod Kumar Large operating systems, large database systems, military command control systems. Extremely large projects :2000-5000 programmers 10 years 1 million-10 million lines Real time processing, telecommunications, multitasking and distributed data processing. For example air traffic control system, ballistic missile defense system Are software projects really different from other projects? Not really! …but… Invisibility Complexity Flexibility Make software more problematic to build than other engineered artifacts. Invisibility - when a physical artifact such a bridge or road is being constructed the progress being made can actually be seen. With software, progress is not immediately visible. Complexity - per dollar, pound or euro spent, software products contain more complexity than other engineered artifacts. Flexibility - the ease with which software can be changed is usually seen as one of its strengths. However this means that where the software system interfaces with a physical or organizational system, it is expected that, where necessary, the software will change to accommodate the other components rather than vice versa. This means the software systems are likely to be subject to a high degree of change. Activities Covered by Project Management Feasibility study Is project technically feasible and worthwhile from a business point of view? Planning Only done if project is feasible Execution Implement plan, but plan may be changed as we go along

Text from page-6

Tutorials - Software Project Management By Vinod Kumar Software Flexibility: The best thing - It can be programmed to do almost anything. The worst thing - The “almost anything” characteristic has made it difficult to plan, monitor, and control software development. In the mid-1990s, three important analyses were performed on the software engineering industry: 1. Software development is still highly unpredictable. Only 10% of software projects are delivered successfully within initial budget and scheduled time. 2. Management discipline is more differentiator in success or failure than are technology advances. 3. The level of software scrap and rework is indicative of an immature process. “The success rate for software projects is very low”

Lecture Notes