This document discusses software project management. It begins by defining what constitutes a project and size categories of software projects from trivial to extremely large. It then addresses that while software projects are similar to other projects, the invisibility of progress, complexity, and flexibility of software make them more difficult to manage. In the 1990s, analyses found that only 10% of software projects were delivered on time and budget, with management discipline being more important than technology. The document goes on to discuss activities covered by project management and introduces the waterfall model for examining software project frameworks both in theory and in practice.
The document discusses software project management. It defines what a project and project management are, and describes the key characteristics of a software project. It outlines several software development lifecycles and methodologies including waterfall, prototype, spiral, agile, Scrum, extreme programming (XP), and rapid application development (RAD). It also discusses software project roles, risk management, project monitoring, defining a lifecycle model, software team organization structures, communication and coordination practices, and factors to consider when selecting a lifecycle model.
Tariq Malik is introducing himself as the instructor for the Software Project Management course. He provides his qualifications including a BSc, MS in IT, and membership in the British Computer Society. He has worked in both the UK and Pakistan as an IT professional and lecturer. The document outlines expectations for students and instructors, contact details for Tariq, details about class discipline, recommended textbooks, certifications, defining projects, software project management, and managing project culture.
Software Project Management | An Overview of the Software Project ManagementAhsan Rahim
Management is the process of getting things done through others, it is the process of coordinating people & other resources to achieve the goals of the organization. A project is a set of related tasks that are coordinated to achieve a specific objective in a given time limit. A project is well-defined task, which is a collection of several operations done in order to achieve a goal. Software is the program & all associated documentation & configuration data which is needed to make these programs operate correctly.
A Software Project is the complete procedure of software development from requirement gathering to testing & maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.
Introduction to Software Project ManagementReetesh Gupta
This document provides an introduction to software project management. It defines what a project and software project management are, and discusses the key characteristics and phases of projects. Software project management aims to deliver software on time, within budget and meeting requirements. It also discusses challenges that can occur in software projects related to people, processes, products and technology. Effective project management focuses on planning, organizing, monitoring and controlling the project work.
This document discusses project scheduling for software engineering projects. It covers key topics such as:
- The importance of scheduling for establishing a roadmap and tracking progress on large, complex software projects.
- Basic principles of software project scheduling including compartmentalizing work, indicating interdependencies, allocating time and resources, and assigning responsibilities.
- Methods for defining tasks, networks, and timelines to plan and track schedules.
- Techniques for monitoring schedule performance such as status meetings, milestone tracking, and earned value analysis.
- Factors that influence schedules such as risks, changing requirements, estimates, and technical difficulties.
This document provides an outline and summary of topics from lectures on software project management and scheduling. It discusses estimating effort, costs, and resources for a project. Other topics covered include the software equation for estimating effort, make-or-buy decisions, outsourcing, reasons for late delivery, and principles of project scheduling such as interdependencies between tasks. It also describes the relationship between people assigned to a project and effort over time based on the Putnam-Norden-Rayleigh curve.
Waterfall vs Agile : A Beginner's Guide in Project ManagementJonathan Donado
The document compares the Waterfall and Agile project management methodologies. Waterfall follows a sequential design process with distinct stages and heavy documentation, while Agile uses short iterative cycles, embraces change, and values team collaboration and customer feedback. Some advantages of Waterfall are its structure and clear expectations, while disadvantages include inflexibility. Agile allows for changes and prioritizes delivering working software frequently for customer input, though the dynamic process may lack formal planning. The document recommends selecting the methodology based on the project's needs and characteristics.
The document discusses software project management. It defines what a project and project management are, and describes the key characteristics of a software project. It outlines several software development lifecycles and methodologies including waterfall, prototype, spiral, agile, Scrum, extreme programming (XP), and rapid application development (RAD). It also discusses software project roles, risk management, project monitoring, defining a lifecycle model, software team organization structures, communication and coordination practices, and factors to consider when selecting a lifecycle model.
Tariq Malik is introducing himself as the instructor for the Software Project Management course. He provides his qualifications including a BSc, MS in IT, and membership in the British Computer Society. He has worked in both the UK and Pakistan as an IT professional and lecturer. The document outlines expectations for students and instructors, contact details for Tariq, details about class discipline, recommended textbooks, certifications, defining projects, software project management, and managing project culture.
Software Project Management | An Overview of the Software Project ManagementAhsan Rahim
Management is the process of getting things done through others, it is the process of coordinating people & other resources to achieve the goals of the organization. A project is a set of related tasks that are coordinated to achieve a specific objective in a given time limit. A project is well-defined task, which is a collection of several operations done in order to achieve a goal. Software is the program & all associated documentation & configuration data which is needed to make these programs operate correctly.
A Software Project is the complete procedure of software development from requirement gathering to testing & maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.
Introduction to Software Project ManagementReetesh Gupta
This document provides an introduction to software project management. It defines what a project and software project management are, and discusses the key characteristics and phases of projects. Software project management aims to deliver software on time, within budget and meeting requirements. It also discusses challenges that can occur in software projects related to people, processes, products and technology. Effective project management focuses on planning, organizing, monitoring and controlling the project work.
This document discusses project scheduling for software engineering projects. It covers key topics such as:
- The importance of scheduling for establishing a roadmap and tracking progress on large, complex software projects.
- Basic principles of software project scheduling including compartmentalizing work, indicating interdependencies, allocating time and resources, and assigning responsibilities.
- Methods for defining tasks, networks, and timelines to plan and track schedules.
- Techniques for monitoring schedule performance such as status meetings, milestone tracking, and earned value analysis.
- Factors that influence schedules such as risks, changing requirements, estimates, and technical difficulties.
This document provides an outline and summary of topics from lectures on software project management and scheduling. It discusses estimating effort, costs, and resources for a project. Other topics covered include the software equation for estimating effort, make-or-buy decisions, outsourcing, reasons for late delivery, and principles of project scheduling such as interdependencies between tasks. It also describes the relationship between people assigned to a project and effort over time based on the Putnam-Norden-Rayleigh curve.
Waterfall vs Agile : A Beginner's Guide in Project ManagementJonathan Donado
The document compares the Waterfall and Agile project management methodologies. Waterfall follows a sequential design process with distinct stages and heavy documentation, while Agile uses short iterative cycles, embraces change, and values team collaboration and customer feedback. Some advantages of Waterfall are its structure and clear expectations, while disadvantages include inflexibility. Agile allows for changes and prioritizes delivering working software frequently for customer input, though the dynamic process may lack formal planning. The document recommends selecting the methodology based on the project's needs and characteristics.
This document summarizes key aspects of quality management and software engineering based on a textbook. It discusses definitions of software quality, types of quality (design and conformance), the costs of quality, software quality assurance techniques like reviews and inspections, roles of a software quality assurance group, metrics for reviews, standards like ISO 9001, change management, software configuration management, and baselines.
This document discusses software project management concepts and processes used at Infosys, a large software company. It covers several key topics:
- The importance of project management and following defined processes. Infosys uses the CMM framework and aims for high maturity.
- How Infosys manages projects, including training for project managers, defining project plans and tracking status during execution.
- The infrastructure used for planning, including a process database of past projects, process capability baselines, and process assets like templates.
- How Infosys tailors its standard development process based on project characteristics. It also describes the change management process.
- The document concludes by covering effort estimation and scheduling concepts used
The seventh lesson of the course on Planning and Managing Software projects (http://emanueledellavalle.org/Teaching/PMSP-2011-12.html) that I give at Politecnico di Milano.
Extreme Programming (XP) is an agile software development methodology that focuses on rapid feedback, simplicity, communication, and responsiveness to change. The key practices of XP include planning game, small releases, simple design, testing, pair programming, collective ownership, continuous integration, on-site customer, and coding standards. XP aims to improve quality and responsiveness through practices like test-driven development, frequent integration, and refactoring.
This document provides an overview of software project management. It begins with introductions and discusses the field of project management, including common jobs, professional organizations, certifications, and tools. It then covers the history of project management and key skills required for project managers, including positions in the field. The document defines what constitutes a software project and explains the engineering and management dimensions. It outlines several classic mistakes to avoid in software project management.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
The document discusses different types of software metrics that can be used to measure various aspects of software development. Process metrics measure attributes of the development process, while product metrics measure attributes of the software product. Project metrics are used to monitor and control software projects. Metrics need to be normalized to allow for comparison between different projects or teams. This can be done using size-oriented metrics that relate measures to the size of the software, or function-oriented metrics that relate measures to the functionality delivered.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
A software process provides stability, control, and organization for software development. It consists of a series of predictable steps that lead to a timely, high-quality product. Key elements include framework activities like planning, modeling, requirements analysis, design, construction, testing, and deployment. The specific tasks and level of rigor for each activity may vary based on the project. Process assessment ensures the process meets criteria for successful software engineering. The primary goal of any process is high-quality software delivered on time through reduced rework.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Introduction to Software Project ManagementSaadi Jadoon
Project management software is software used for project planning, scheduling, resource allocation and change management. It allows project managers (PMs), stakeholders and users to control costs and manage budgeting, quality management and documentation and also may be used as an administration system.
Introduction of software project managementREHMAT ULLAH
This document discusses software project management. It defines software project management as a process of managing, allocating, and timing resources to develop computer software that meets requirements. The document outlines the key tasks in software project management, including problem identification, definition, planning, organization, resource allocation, scheduling, tracking, reporting, controlling, and project termination. It emphasizes that software project management plans, implements, monitors, and controls software projects from start to finish.
The document discusses Agile methodology, which is an iterative software development approach based on self-organizing teams. It describes when Agile is useful, such as for complicated projects or when requirements are unclear. Specific Agile methods like Scrum are outlined, including Scrum roles, sprints, and meetings. Advantages include rapid delivery and adaptation, while disadvantages include potential lack of documentation. Tools can help with requirements, planning, tracking, and quality assurance in Agile projects.
The document provides an overview of agile methodology and scrum framework. It begins with a short history of traditional waterfall software development processes and their limitations. It then introduces the agile manifesto and values, as well as the 12 agile principles. A key part of agile is iterative development with short sprints. Scrum is discussed as one of the major agile frameworks, outlining its ceremonies like sprint planning, daily standups, and retrospectives. Scrum roles of product owner, scrum master, and self-organizing team are also summarized.
Increase productivity and improve the predictability of software projects. Interest in the Scrum Agile process framework is exploding as companies discover that Scrum enables them to manage software projects with greater reliability and improve responsiveness to customers. This class introduces the skills that project managers and team leaders need to perform the basic steps of a Scrum process for software development.
-Learn how Scrum practices relate to project management fundamentals
-Learn the essentials of Scrum as a software development process
-Learn the three Scrum roles, three Scrum meetings, and three Scrum artifacts
-Project Managers and team leads learn basic planning, tracking, and management skills
-Product Managers learn how to develop and prioritize requirements
-Team members learn how to estimate and break down work
This document summarizes key aspects of process improvement discussed in two lectures. It discusses the process improvement process, including process measurement, analysis, and change. It describes approaches like the CMMI framework and how it is used to assess process maturity levels. It outlines the stages of process change and challenges like resistance to change.
Lect-5: Work Breakdown Structure and Project Cost EstimationMubashir Ali
This document discusses work breakdown structures (WBS) and project cost estimation. It begins by defining a WBS as a method to divide complex projects into simpler, manageable tasks. This allows projects to be more easily planned, scheduled, and budgeted. The document then provides examples of how to outline a WBS and discusses how WBS helps managers assign responsibilities and monitor projects. It also discusses different cost estimation techniques like expert judgement, analogy, and algorithmic modeling. Overall, the document provides an overview of how WBS is used to define project scope and organize work, and different approaches to estimating project costs.
FDD is a software development process that is client-centric, architecture-centric, and pragmatic. It focuses on developing features, which are small client-valued functions. Key aspects of FDD include developing an overall model, building a prioritized feature list, planning by feature, designing by feature, and building by feature in an iterative process. FDD was created by Jeff DeLuca in 1997 for a banking project and combines techniques like modeling, domain-driven design, and agile practices like XP.
The document discusses project planning in software engineering. It defines project planning and its importance. It describes the project manager's responsibilities which include project planning, reporting, risk management, and people management. It discusses challenges in software project planning. The RUP process for project planning is then outlined which involves creating artifacts like the business case and software development plan. Risk management is also a key part of project planning.
This document discusses improving software economics through reducing software size, improving development processes, using skilled personnel, and leveraging better development environments and tools. It outlines cost estimation formulas and trends in programming languages, object-oriented methods, reuse, and commercial components that can reduce software size. The document also describes improving processes at the meta, macro and micro levels and how this can improve predictability, schedules and quality.
This document discusses software project management artifacts. Artifacts are organized into management and engineering sets. The management set includes artifacts like the work breakdown structure, business case, and software development plan. The engineering set includes requirement, design, implementation, and deployment artifact sets. Each set captures information through various notations and tools to manage the software development lifecycle.
This document summarizes key aspects of quality management and software engineering based on a textbook. It discusses definitions of software quality, types of quality (design and conformance), the costs of quality, software quality assurance techniques like reviews and inspections, roles of a software quality assurance group, metrics for reviews, standards like ISO 9001, change management, software configuration management, and baselines.
This document discusses software project management concepts and processes used at Infosys, a large software company. It covers several key topics:
- The importance of project management and following defined processes. Infosys uses the CMM framework and aims for high maturity.
- How Infosys manages projects, including training for project managers, defining project plans and tracking status during execution.
- The infrastructure used for planning, including a process database of past projects, process capability baselines, and process assets like templates.
- How Infosys tailors its standard development process based on project characteristics. It also describes the change management process.
- The document concludes by covering effort estimation and scheduling concepts used
The seventh lesson of the course on Planning and Managing Software projects (http://emanueledellavalle.org/Teaching/PMSP-2011-12.html) that I give at Politecnico di Milano.
Extreme Programming (XP) is an agile software development methodology that focuses on rapid feedback, simplicity, communication, and responsiveness to change. The key practices of XP include planning game, small releases, simple design, testing, pair programming, collective ownership, continuous integration, on-site customer, and coding standards. XP aims to improve quality and responsiveness through practices like test-driven development, frequent integration, and refactoring.
This document provides an overview of software project management. It begins with introductions and discusses the field of project management, including common jobs, professional organizations, certifications, and tools. It then covers the history of project management and key skills required for project managers, including positions in the field. The document defines what constitutes a software project and explains the engineering and management dimensions. It outlines several classic mistakes to avoid in software project management.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
The document discusses different types of software metrics that can be used to measure various aspects of software development. Process metrics measure attributes of the development process, while product metrics measure attributes of the software product. Project metrics are used to monitor and control software projects. Metrics need to be normalized to allow for comparison between different projects or teams. This can be done using size-oriented metrics that relate measures to the size of the software, or function-oriented metrics that relate measures to the functionality delivered.
The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.
A software process provides stability, control, and organization for software development. It consists of a series of predictable steps that lead to a timely, high-quality product. Key elements include framework activities like planning, modeling, requirements analysis, design, construction, testing, and deployment. The specific tasks and level of rigor for each activity may vary based on the project. Process assessment ensures the process meets criteria for successful software engineering. The primary goal of any process is high-quality software delivered on time through reduced rework.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Introduction to Software Project ManagementSaadi Jadoon
Project management software is software used for project planning, scheduling, resource allocation and change management. It allows project managers (PMs), stakeholders and users to control costs and manage budgeting, quality management and documentation and also may be used as an administration system.
Introduction of software project managementREHMAT ULLAH
This document discusses software project management. It defines software project management as a process of managing, allocating, and timing resources to develop computer software that meets requirements. The document outlines the key tasks in software project management, including problem identification, definition, planning, organization, resource allocation, scheduling, tracking, reporting, controlling, and project termination. It emphasizes that software project management plans, implements, monitors, and controls software projects from start to finish.
The document discusses Agile methodology, which is an iterative software development approach based on self-organizing teams. It describes when Agile is useful, such as for complicated projects or when requirements are unclear. Specific Agile methods like Scrum are outlined, including Scrum roles, sprints, and meetings. Advantages include rapid delivery and adaptation, while disadvantages include potential lack of documentation. Tools can help with requirements, planning, tracking, and quality assurance in Agile projects.
The document provides an overview of agile methodology and scrum framework. It begins with a short history of traditional waterfall software development processes and their limitations. It then introduces the agile manifesto and values, as well as the 12 agile principles. A key part of agile is iterative development with short sprints. Scrum is discussed as one of the major agile frameworks, outlining its ceremonies like sprint planning, daily standups, and retrospectives. Scrum roles of product owner, scrum master, and self-organizing team are also summarized.
Increase productivity and improve the predictability of software projects. Interest in the Scrum Agile process framework is exploding as companies discover that Scrum enables them to manage software projects with greater reliability and improve responsiveness to customers. This class introduces the skills that project managers and team leaders need to perform the basic steps of a Scrum process for software development.
-Learn how Scrum practices relate to project management fundamentals
-Learn the essentials of Scrum as a software development process
-Learn the three Scrum roles, three Scrum meetings, and three Scrum artifacts
-Project Managers and team leads learn basic planning, tracking, and management skills
-Product Managers learn how to develop and prioritize requirements
-Team members learn how to estimate and break down work
This document summarizes key aspects of process improvement discussed in two lectures. It discusses the process improvement process, including process measurement, analysis, and change. It describes approaches like the CMMI framework and how it is used to assess process maturity levels. It outlines the stages of process change and challenges like resistance to change.
Lect-5: Work Breakdown Structure and Project Cost EstimationMubashir Ali
This document discusses work breakdown structures (WBS) and project cost estimation. It begins by defining a WBS as a method to divide complex projects into simpler, manageable tasks. This allows projects to be more easily planned, scheduled, and budgeted. The document then provides examples of how to outline a WBS and discusses how WBS helps managers assign responsibilities and monitor projects. It also discusses different cost estimation techniques like expert judgement, analogy, and algorithmic modeling. Overall, the document provides an overview of how WBS is used to define project scope and organize work, and different approaches to estimating project costs.
FDD is a software development process that is client-centric, architecture-centric, and pragmatic. It focuses on developing features, which are small client-valued functions. Key aspects of FDD include developing an overall model, building a prioritized feature list, planning by feature, designing by feature, and building by feature in an iterative process. FDD was created by Jeff DeLuca in 1997 for a banking project and combines techniques like modeling, domain-driven design, and agile practices like XP.
The document discusses project planning in software engineering. It defines project planning and its importance. It describes the project manager's responsibilities which include project planning, reporting, risk management, and people management. It discusses challenges in software project planning. The RUP process for project planning is then outlined which involves creating artifacts like the business case and software development plan. Risk management is also a key part of project planning.
This document discusses improving software economics through reducing software size, improving development processes, using skilled personnel, and leveraging better development environments and tools. It outlines cost estimation formulas and trends in programming languages, object-oriented methods, reuse, and commercial components that can reduce software size. The document also describes improving processes at the meta, macro and micro levels and how this can improve predictability, schedules and quality.
This document discusses software project management artifacts. Artifacts are organized into management and engineering sets. The management set includes artifacts like the work breakdown structure, business case, and software development plan. The engineering set includes requirement, design, implementation, and deployment artifact sets. Each set captures information through various notations and tools to manage the software development lifecycle.
Change management in Software EngineeringHiba Ghannam
This document discusses change management in software engineering. It defines change management as guiding how organizations prepare for, equip individuals for, and support adoption of changes to drive success. The sources of change in software engineering include new requirements, errors that must be repaired. The objective is to maximize speed and minimize costs while controlling risks. The procedures discussed are request review, planning, approval, implementation and closure. Key roles include initiators, coordinators, managers and approvers. The process involves creating requests, reviewing/assessing them, planning, testing, creating proposals, implementing and reviewing changes. Tools mentioned are bug tracking, requirements and task management, and code management. Tips provided are thorough testing, knowing users, not rushing, testing changes
This document provides an overview of software testing concepts and processes. It discusses the importance of testing in the software development lifecycle and defines key terms like errors, bugs, faults, and failures. It also describes different types of testing like unit testing, integration testing, system testing, and acceptance testing. Finally, it covers quality assurance and quality control processes and how bugs are managed throughout their lifecycle.
This document discusses various types of software testing techniques used in the software development lifecycle (SDLC). It begins by describing different SDLC models like waterfall, prototyping, RAD, spiral and V-models. It then discusses the importance of testing at different stages of SDLC and different types of testing like static vs dynamic, black box vs white box, unit vs integration etc. The rest of the document elaborates on specific black box and white box testing techniques like equivalence partitioning, boundary value analysis, cause-effect graphing, statement coverage and basis path testing.
Testing is the process of identifying bugs and ensuring software meets requirements. It involves executing programs under different conditions to check specification, functionality, and performance. The objectives of testing are to uncover errors, demonstrate requirements are met, and validate quality with minimal cost. Testing follows a life cycle including planning, design, execution, and reporting. Different methodologies like black box and white box testing are used at various levels from unit to system. The overall goal is to perform effective testing to deliver high quality software.
The document discusses various aspects of software project management including project planning activities like estimation, scheduling, staffing, and risk handling. It describes different project organization structures like functional organization and project organization. It also discusses different team structures like chief programmer teams, democratic teams, and mixed teams. The document emphasizes the importance of careful project planning and producing a software project management plan document. It also discusses considerations for staffing a project team and attributes of a good software engineer.
The document provides information on various topics related to software engineering:
1. It defines software engineering and discusses why it is required to manage large, scalable software projects and improve quality and cost management.
2. It describes common software processes like specification, development, validation and evolution and different process models like waterfall, iterative and prototyping.
3. It discusses the "software crisis" due to increasing size, costs and delays in software projects and differentiates between a program and software.
4. It explains popular process models like waterfall, iterative and prototyping in detail outlining their phases, advantages and disadvantages.
This document outlines the objectives and content of the IT8075 Software Project Management course. The course aims to teach students how to plan, manage, and deliver successful software projects. It covers topics such as project planning, estimation techniques, risk management, project monitoring and control, and people management. The course is divided into 5 units which cover areas such as the software development life cycle, effort estimation methods, scheduling, risk analysis, and staff management in projects. The intended learning outcomes include understanding basic project management principles and gaining knowledge of processes, estimation, risk identification, and using principles to define project structure and track progress.
Software engineering is the application of engineering principles and methods to the development of software. It involves developing software products using well-defined scientific principles, methods, and procedures. The role of software has evolved significantly over the past 50 years from standalone programs to complex systems that deliver both information and control functions. Addressing the "software crisis" of the 1960s required treating software development as an engineering discipline with processes, documentation, and quality assurance rather than an art. Applying software engineering principles and practices was seen as a solution to issues like projects running over budget and schedule, producing inefficient and low-quality software that did not meet requirements.
This document provides an overview of software engineering concepts covered in lecture notes. It discusses the software development life cycle (SDLC) which includes key stages like requirements gathering, design, coding, testing, integration and maintenance. The SDLC framework aims to develop software efficiently using a well-defined process. Software engineering principles like abstraction and decomposition are used to reduce complexity when developing large programs.
The document discusses software process models. It describes the waterfall model, which is a generic process framework for software engineering that defines five framework activities: communication, planning, modeling, construction, and deployment. It also discusses umbrella activities that are applied throughout the process, such as project tracking and control. The waterfall model prescribes distinct activities, actions, tasks, milestones, and work products for software development. However, process models need to be adapted to meet the needs of specific projects.
SWE-401 - 3. Software Project Managementghayour abbas
The document discusses various aspects of software project management including defining a software project, the need for software project management, roles and responsibilities of a project manager, key project management activities like planning, estimation, scheduling, resource management, risk management, execution and monitoring, communication management, configuration management, and change control. It also discusses tools that can help with project management like Gantt charts, PERT charts, resource histograms, and critical path analysis.
This document discusses agile software development processes. It outlines some common reasons for challenged, failed, and successful projects. Some key problems with the traditional waterfall model are that mistakes are hard to find early on and requirements often change. The document then introduces agile concepts like iterative development, test-driven development, extreme programming, scrum, and their benefits like producing working software earlier, adapting to change, and improved communication.
The document provides an introduction to software engineering concepts. It discusses how software engineering aims to develop reliable software products using well-defined scientific principles and methods. It covers software evolution, different software paradigms including development, design and programming paradigms. It also discusses different software life cycle models like waterfall, incremental, prototyping and spiral models. Finally, it talks about characteristics of good software products and causes of software crisis.
The document discusses the need for software engineering principles in developing large software products. It notes that while small programs can be written without engineering principles, large products require a systematic approach to achieve good quality cost-effectively. It also summarizes factors that impact software quality and productivity, including product complexity, team communication challenges, appropriate notations, and the level of technology used. Project size is a major determinant of management control needs and techniques required.
The document provides an overview of software engineering. It defines software engineering as applying scientific principles and methods to the development of software. The document then discusses the need for software engineering due to factors like managing large or scalable software, cost management, and dynamic nature of software. It also covers key concepts in software engineering like product vs process, software evolution, software development life cycle (SDLC), different SDLC models like waterfall, incremental, iterative and evolutionary.
The document provides an overview of software engineering. It defines software engineering as applying scientific principles and methods to the development of software. The document then discusses the need for software engineering due to factors like managing large or scalable software, cost management, and dynamic nature of software. It also covers key concepts in software engineering like product vs process, software evolution, software development life cycle (SDLC), different SDLC models like waterfall, incremental, iterative and evolutionary models.
This document provides an overview of software engineering concepts including:
1. Software can be both a product and a means to deliver a product, transforming data in simple or complex ways. Software is defined as instructions, data structures, and documentation.
2. Software engineering is the systematic development of software using theories, methods, and tools. It produces software products through defined processes, methods, and management activities.
3. Common software process models include waterfall, incremental, evolutionary (like prototyping and spiral), and concurrent development models. Each has advantages and disadvantages depending on the project.
The document discusses software project management. It defines a software project as the process of software development from requirements gathering through testing and maintenance according to methodologies within a specified time frame and budget. It notes that software projects require management due to their unique nature, intangible product, and rapidly changing technologies. The responsibilities of a software project manager are outlined as managing people, the project, risks, and acting as a liaison and spokesperson. Key software management activities discussed include project planning, scope management, estimation, tracking resources, scheduling, communication, and configuration management.
What is project? Software Project Vs. Other Types. Activities by
Software Project Mgt. Plans, Methods and Methodologies. Problems with Software Projects.
fter Completing this chapter you should be able to:
understand what software engineering is and why it is important;
understand the concepts of software processes and software process models;
Compare and contrast a variety of models
understand some ethical and professional issues that are important for software engineers;
Today as we see, software has become an inseparable part of human life. Almost everything we can look around is managed, controlled by software.
The goal of software project management is to understand, plan, measure, and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process.
construction management system final year reportchiragbarasiya
This document provides an overview and details of a construction management system project. It includes 5 chapters that cover:
1) An introduction to the system including its modules, functionality, and technologies used
2) Project management details such as the development model, planning, scheduling, and risk management
3) System requirements including hardware, software, and feasibility analysis
4) System analysis including use cases, data flow diagrams, and entity relationship diagrams
5) System design including the user interface, database structure, and sequence diagrams
It aims to develop a user-friendly website to manage construction projects and reduce paperwork through various administrative and member functions.
importance of resources allocation in formal method of software engineering ...abdulrafaychaudhry
This document discusses key concepts related to project management including resource allocation, software risks, differences between products and projects, discount factors, net present value, and net profit.
The main points are:
1) Resource allocation in project management is important for planning, scheduling, and controlling workload to improve team effectiveness. It involves identifying and tracking resources like budget, tools, and time.
2) The top five software risks are inherent schedule flaws, requirements inflation, employee turnover, specification breakdown, and poor productivity. Agile methods aim to mitigate these risks through practices like iterative planning and prioritization.
3) The key difference between a product and project is that a product is manufactured and sold while a project is built to
importance of resources allocation in formal method of software engineering ...
Spm tutorials
1. Tutorials - Software Project Management
By Vinod Kumar
In this introduction, the main topics to be addressed will be:
What is software project management?
Discuss projects characteristics and its size categories.
Are software projects really different from other projects?
Software activities and flexibilities covered by project management.
Waterfall model: in theory and in practice.
What exactly do we mean by Software Project Management? To answer this, we need to look at
some key ideas about the planning, monitoring and control of software projects.
Projects to produce software are worthwhile only if they satisfy real needs and so we will
examine how we can identify the stakeholders in a project and their objectives.
Identifying those objectives and checking that they are met is the basis of a successful project.
This, however, cannot be done unless there is accurate information and how this is provided will
be explored.
WHAT IS A PROJECT?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works scheme”
Longmans dictionary
The dictionary definitions put a clear emphasis on the project’s being a planned activity.
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
Lecture Notes
have developed will have a large element of the routine.
SOFTWARE + PROJECT + MANAGEMENT
Software Project is a combination of tools and techniques and its methodologies used for
SOFTWARE PROJECT MANAGEMENT
specific purpose.
Management is a activity, which comprises of some functions which are : Planning, Organizing,
Staffing, Directing and Controlling.
2. 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!
3. 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 - Non-routine tasks are involved
Planned - 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 <500 statements
10 to 20 subroutines
Small projects :-
One programmer 1 to 6 months
1000-2000 lines 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
4. 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
5. 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”
6. Tutorials - Software Project Management
By Vinod Kumar
CONVENTIONAL SOFTWARE MANAGEMENT
1. The best thing about software is its flexibility:
- It can be programmed to do almost anything.
2. The worst thing about software is its flexibility:
- The “almost anything” characteristic has made it difficult to plan, monitor, and control
software development.
3. In the mid-1990s, three important analyses were performed on the software engineering
industry.
All three analyses given the same general conclusion:-
“The success rate for software projects is very low”.
They summarized as follows:
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.
Software management process framework:
WATERFALLL MODEL
1. It is the baseline process for most conventional software projects have used.
2. We can examine this model in two ways:
(i) IN THEORY
(ii) IN PRACTICE
IN THEORY:-
In 1970, Winston Royce (he was the father of Walker Royce) presented a paper called
“Managing the Development of Large Scale Software Systems” at IEEE WESCON.
Where he made three primary points:
1.There are two essential steps common to the development of computer programs:
- analysis
- coding
7. Tutorials - Software Project Management
By Vinod Kumar
2. In order to mange and control all of the intellectual freedom associated with software
development one should follow the following steps:
- System requirements definition
- Software requirements definition
- Program design and testing
These steps addition to the analysis and coding steps
3. Since the testing phase is at the end of the development cycle in the waterfall model, it may be
risky and invites failure. So we need to do either the requirements must be modified or a
substantial design changes is warranted by breaking the software in to different pieces.
There are five improvements to the basic waterfall model that would eliminate most of the
development risks are as follows:
a) Complete program design before analysis and coding begin (program design comes first):-
- By this technique, the program designer give surety that the software will not fail because of
storage, timing, and data fluctuations.
- Begin the design process with program designer, not the analyst or programmers.
- Write an overview document that is understandable, informative, and current so that every
worker on the project can gain an elemental understanding of the system.
b) Maintain current and complete documentation (Document the design):-
8. Tutorials - Software Project Management
By Vinod Kumar
-It is necessary to provide a lot of documentation on most software programs.
- Due to this, helps to support later modifications by a separate test team, a separate maintenance
team, and operations personnel who are not software literate.
c) Do the job twice, if possible (Do it twice):-
- If a computer program is developed for the first time, arrange matters so that the version finally
delivered to the customer for operational deployment is actually the second version insofar as
critical design/operations are concerned.
- “Do it N times” approach is the principle of modern-day iterative development.
d) Plan, control, and monitor testing:-
- The biggest user of project resources is the test phase. This is the phase of greatest risk in terms
of cost and schedule.
- In order to carryout proper testing the following things to be done:
i) Employ a team of test specialists who were not responsible for the original design.
ii) Employ visual inspections to spot the obvious errors like dropped minus signs, missing factors
of two, jumps to wrong addresses.
iii) Test every logic phase.
iv) Employ the final checkout on the target computer.
e) Involve the customer:-
- It is important to involve the customer in a formal way so that he has committed himself at
earlier points before final delivery by conducting some reviews such as,
i) Preliminary software review during preliminary program design step.
ii) Critical software review during program design.
iii) Final software acceptance review following testing.
IN PRACTICE:-
- Whatever the advices that are given by the software developers and the theory behind the
waterfall model, some software projects still practice the conventional software management
approach.
Projects intended for trouble frequently exhibit the following symptoms:
i) Protracted (delayed) integration
- In the conventional model, the entire system was designed on paper, then implemented all at
once, then integrated. Only at the end of this process was it possible to perform system testing to
verify that the fundamental architecture was sound.
- Here the testing activities consume 40% or more life-cycle resources.
9. Tutorials - Software Project Management
By Vinod Kumar
ACTIVITY COST
Management 5%
Requirements 5%
Design 10%
Code and unit testing 30%
Integration and test 40%
Deployment 5%
Environment 5%
ii) Late Risk Resolution
- A serious issues associated with the waterfall life cycle was the lack of early risk resolution.
The risk profile of a waterfall model is,
10. Tutorials - Software Project Management
By Vinod Kumar
- It includes four distinct periods of risk exposure, where risk is defined as “the probability of
missing a cost, schedule, feature, or quality goal”.
iii) Requirements-Driven Functional Decomposition
-Traditionally, the software development process has been requirement-driven: An attempt is
made to provide a precise requirements definition and then to implement exactly those
requirements.
-This approach depends on specifying requirements completely and clearly before other
development activities begin.
- It frankly treats all requirements as equally important.
- Specification of requirements is a difficult and important part of the software development
process.
iv) Adversarial Stakeholder Relationships
The following sequence of events was typical for most contractual software efforts:
- The contractor prepared a draft contact-deliverable document that captured an intermediate
artifact and delivered it to the customer for approval.
- The customer was expected to provide comments (within 15 to 30 days)
- The contractor integrated these comments and submitted a final version for approval (within 15
to 30 days)
Project Stakeholders :
Stakeholders are the people involved in or affected by project activities.
Stakeholders include :
o project sponsor
o project team
o support staff
o customers
o users
o suppliers
o opponents to the project
v) Focus on Documents and Review Meetings
- The conventional process focused on various documents that attempted to describe the software
product.
- Contractors produce literally tons of paper to meet milestones and demonstrate progress to
stakeholders, rather than spend their energy on tasks that would reduce risk and produce quality
software.
- Most design reviews resulted in low engineering and high cost in terms of the effort and
schedule involved in their preparation and conduct.
13. Tutorials - Software Project Management
By Vinod Kumar
Conventional Software Management Performance
Barry Boehm’s Top 10 “Industrial Software Metrics”:
1) Finding and fixing a software problem after delivery costs 100 times more than finding and
fixing the problem in early design phases.
2) You can compress software development schedules 25% of nominal (small), but no more.
3) For every $1 you spend on development, you will spend $2 on maintenance.
4) Software development and maintenance costs are primarily a function of the number of source
lines of code.
5) Variations among people account for the biggest difference in software productivity.
6) The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985,
85:15.
7) Only about 15% of software development effort is devoted to programming.
8) Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software-system products cost 9 times as much.
9) Walkthroughs catch 60% of the errors.
10) 80% of the contribution comes from 20% of the contributors.
- 80% of the engineering is consumed by 20% of the requirements.
- 80% of the software cost is consumed by 20% of the components.
- 80% of the errors are caused by 20% of the components.
- 80% of the software scrap and rework is caused by 20% of the errors.
- 80% of the resources are consumed by 20% of the components.
- 80% of the engineering is accomplished by 20% of the tools.
- 80% of the progress is made by 20% of the people.
14. Tutorials - Software Project Management
By Vinod Kumar
EVOLUTION OF SOFTWARE ECONOMICS
Economics is a social science activity which deals with distribution and consumption of goods
and services. Economics means System of interrelationship of money, industry and employment.
Software Economics:-
The cost of the software can be estimated by considering the following 5 basic things as :
1)Size: Which is measured in terms of the number of Source Lines Of Code or the number of
function points required to develop the required functionality.
2)Process: Used to produce the end product, in particular the ability of the process is to avoid
nonvalue-adding activities (rework, bureaucratic delays, communications overhead).
3)Personnel: The capabilities of software engineering personnel, and particularly their
experience with the computer science issues and the application domain issues of the project.
4)Environment: Which is made up of the tools and techniques available to support efficient
software development and to automate the process.
5)Quality: It includes its features, performance, reliability, and flexibility. The relationship
among these parameters and estimated cost can be calculated by using,
Effort = (Personnel) (Environment) (Quality) (SizeProcess)
- Software economics is the relationship between effort (estimated cost) and size exhibits a
diseconomy of scale and is the result of the process exponent being greater than 1.0.
DISECONOMY OF SCALE of software development means -
the result of process exponent being greater than 1.0
- Converse to most manufacturing processes, the more software you build, the more expensive it
is per unit item.
- There are three generations of basic technology advancement in tools, components, and
processes are available.
1) Conventional: 1960 and 1970, Craftsmanship. Organizations used custom tools, custom
processes, and virtually all custom components built in primitive languages. Project performance
was highly predictable.
2) Transition: 1980 and 1990, software engineering. Organizations used more-repeatable
processes and off-the-shelf tools, and mostly (>70%) custom components built in higher level
languages.
OFF-THE-SHELF means- Especially of clothing (Ready made jackets) Mass production given
low costs.
15. Tutorials - Software Project Management
By Vinod Kumar
COTS (Commercial Off-The-Shelf)
MOTS (Modified/Military Off-The-Shelf) : Government agency neglect MOTS software as fear
that future change of product will be out of control.
GOTS (Government Off-The-Shelf) : Government technical staff developed a software to
control all the aspects.
- Some of the components (<30%) were available as commercial products like, OS, DBMS,
Networking and GUI.
3) Modern practices: 2000 and later, software production.
- 70% component-based,
- 30% custom
Conventional Transition Modern Practices
- 1960s - 1970s - 1980s -1990s - 2000 and on
- Waterfall model - Process improvement - Iterative development
- Functional design - Encapsulation - based - Component-based
- Diseconomy of scale - Diseconomy of scale - ROI
Environments/Tools :
Custom Off-the-shelf, separate Off-the-shelf, Integrated
Size :
100% custom 30% component-based 70% custom
70% component-based 30% custom
CUSTOM BASED TOOL means -
– According to problem – Based on requirement
COMPONENT BASED TOOLS means -
– Already coding is maintained – Engineers are customers – We can reuse coding
– General coding is used
Process :
Ad hoc Repeatable Managed/measured
Typical Project Performance :
Always: Infrequently: Usually:
Over budget On budget On budget
Over schedule On schedule On schedule
What Does Return On Investment - ROI Means Profit.
A performance measure used to evaluate the efficiency of an investment or to compare the
efficiency of a number of different investments. To calculate ROI, the benefit (return) of an
investment is divided by the cost of the investment; the result is expressed as a percentage or a
ratio.
16. Tutorials - Software Project Management
By Vinod Kumar
The return on investment formula:
Return on investment is a very popular metric because of its versatility and simplicity. That is, if
an investment does not have a positive ROI, or if there are other opportunities with a higher ROI,
then the investment should be not be undertaken
Project Sizes :
• Size as team strength could be :
– Trivial (Minor) Size: 1 person
– Small Size: 5 people
– Moderate Size: 25 people
– Large Size: 125 people
– Huge Size: 625 people
• The more the size, the greater are the costs of management overhead, communication,
synchronizations among various projects or modules, etc.
The other factures for the software economics are time and cost.
Time –To reduce time:
1. In order to reduce the development time for a software project, there may be multiple
teams of few members, but not a single group.
2. The team should be balanced, so that there should not be communication gap or
technological gap between the team members.
3. The team members should be equally skilled in a particular technology.
4. There must be a leader in a team.
Cost –To reduce cost:
1. The cost of software project can be minimized by adopting COTS (Component Off The
Shelf). COTS are the components available to be reused in the software development
process.
2. Identify the risk and try to overcome in the planning phase of the project.
3. The requirement of the customer must be thoroughly analyzed before initiating the
project.
4. Complexity of the software should be decreased.
17. Tutorials - Software Project Management
By Vinod Kumar
Examples are:
1. Instruction Statement Program Software Application
Complexity Increase Complexity Decrease
2.
Application
Gate IC Card Rack
Higher Complexity Lower Complexity
Reduce Software Size:
The less software we write, the better it is for project management and for product quality
- The cost of software is not just in the cost of ‘coding’ alone; it is also in Analysis of
requirements
– Design
– Review of requirements, design and code
85% – Test Planning and preparation
– Testing
– Bug fix
– Regression testing
– ‘Coding’ takes around 15% of development cost
- Clearly, if we reduce 15 hrs of coding, we can directly reduce 100 hrs of development
effort, and also reduce the project team size appropriately !
- Size reduction is defined in terms of human-generated source code. Most often, this
might still mean that the computer-generated executable code is at least the same or even
more - Software Size could be reduced by
– Software Re-use
– Use of COTS (Commercial Off-The Shelf Software)
– Programming Languages
PRAGMATIC SOFTWARE ESTIMATION:
PRAGMATIC means – it is relating to affairs of the state or history.
- If there is no proper well-documented case studies then it is difficult to estimate the cost of the
software. It is one of the critical problems in software cost estimation.
- But the cost model vendors claim that their tools are well suitable for estimating iterative
development projects.
- In order to estimate the cost of a project the following three topics should be considered,
1) Which cost estimation model to use?
2) Whether to measure software size in SLOC or function point.
3) What constitutes a good estimate?
18. Tutorials - Software Project Management
By Vinod Kumar
- There are a lot of software cost estimation models are available such as, COCOMO,
CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S, ProQMS, SEER, SLIM, SOFTCOST,
and SPQR/20, Ada.
COCOMO (Conventional Cost Model)
SPQR (The Senate & The Rome or The Senatus Populusque Romanus)
- Of which COCOMO is one of the most open and well-documented cost estimation models
- The software size can be measured by using
1) SLOC
- 1,000 Source Line Of Cost
2) Function points
- 20 Functions points - 6 Classes - 5 Use case - Object points - Files
- Sub-system - 1 Component
- Most software experts argued that the SLOC is a poor measure of size. But it has some value in
the software Industry.
- SLOC worked well in applications that were custom built why because of easy to automate and
instrument.
- Now days there are so many automatic source code generators are available and there are so
many advanced higher-level languages are available. So SLOC is a uncertain measure.
- The main advantage of function points is that this method is independent of the technology and
is therefore a much better primitive unit for comparisons among projects and organizations.
- The main disadvantage of function points is that the primitive definitions are abstract and
measurements are not easily derived directly from the evolving artifacts.
- Function points is more accurate estimator in the early phases of a project life cycle. In later
phases, SLOC becomes a more useful and precise measurement basis of various metrics
perspectives.
- The most real-world use of cost models is bottom-up rather than top-down.
- The software project manager defines the target cost of the software, then manipulates the
parameters and sizing until the target cost can be justified.
19. Tutorials - Software Project Management
By Vinod Kumar
IMPROVING SOFTWARE ECONOMICS
- It is not that much easy to improve the software economics but also difficult to measure and
validate.
- There are many aspects are there in order to improve the software economics they are, Size,
Process, Personnel, Environment and quality.
- These parameters (aspects) are not independent they are dependent. For example, tools enable
size reduction and process improvements, size-reduction approaches lead to process changes,
and process improvements drive tool requirements.
- GUI technology is a good example of tools enabling a new and different process. GUI builder
tools permitted engineering teams to construct an executable user interface faster and less cost.
- Two decades ago, teams developing a user interface would spend extensive time analyzing
factors, screen layout, and screen dynamics. All this would do on paper. Where as by using GUI,
the paper descriptions are not necessary.
- Along with these five basic parameters another important factor that has influenced software
technology improvements across the board is the ever-increasing advances in hardware
performance.
Reducing Software Product Size:
- By choosing the type of the language
- By using Object-Oriented methods and visual modeling
- By reusing the existing components and building reusable components &
20. Tutorials - Software Project Management
By Vinod Kumar
- By using commercial components, we can reduce the product size of a software.
Here UPFs (Universal Function Points) are useful estimators for language-independent in the
early life cycle phases. The basic units of function points are:
- External user inputs
- External outputs
- Internal logical data groups
- External data Interfaces
- External inquiries
Object Oriented Methods And Visual Modeling:
- There has been a widespread movement in the 1990s toward Object-Oriented technology.
- Some studies concluded that Object-Oriented programming languages appear to benefit both
software productivity and software quality. One of such Object-Oriented method is UML
(Unified Modeling Language).
Booch described the following three reasons for the success of the projects that are using
Object-Oriented concepts:
21. Tutorials - Software Project Management
By Vinod Kumar
1) An OO-model of the problem and its solution encourages a common vocabulary between the
end user of a system and its developers, thus creating a shared understanding of the problem
being solved.
2) The use of continuous integration creates opportunities to recognize risk early and make
incremental corrections without weaken the entire development effort.
3) An OO-architecture provides a clear separation among different elements of a system, crating
firewalls that prevent a change in one part of the system from the entire architecture.
He also suggested five characteristics of a successful OO-Project,
1) A cruel focus on the development of a system that provides a well understood collection of
essential minimal characteristics.
2) The existence of a culture that is centered on results, encourages communication, and yet is
not afraid to fail.
3) The effective use of OO-modeling.
4) The existence of a strong architectural vision.
5) The application of a well-managed iterative and incremental development life cycle.
Reuse:
An organization that translates reusable components into commercial products has the following
characteristics:
- They have an economic motivation for continued support.
- They take ownership of improving product quality, adding new features and transitioning to
new technologies.
22. Tutorials - Software Project Management
By Vinod Kumar
Commercial Components
Improving Software Processes:
There are three distinct process perspectives:
1) Meta process:
- It is an Organization’s policies, procedures, and practices for pursuing software intensive line
of business.
- The focus of this process is of organizational economics, long-term strategies, and software
ROI.
2) Macro process:
- A project’s policies, and practices for producing a complete software product within certain
cost, schedule, and quality constraints.
- The focus of the macro-process is on creating a sufficient instance of the meta process for a
specific set of constraints.
3) Micro process:
- A projects team’s policies, procedures, and practices for achieving an artifact of a software
process.
- The focus of the micro-process is on achieving an intermediate product baseline with sufficient
functionality as economically and rapidly as practical. The objective of process improvement is
to maximize the allocation of resources to productive activities and minimize the impact of
overhead activities on resources such as personnel, computers, and schedule.
23. Tutorials - Software Project Management
By Vinod Kumar
Improving Team Effectiveness:
Means – Just formulate a good team.
- COCOMO model suggests that the combined effects of personnel skill and experience can have
an impact on productivity as much as a factor of four over the unskilled personnel.
- Balance and coverage are two of the most important features of excellent teams. Whenever a
team is in out of balance then it is vulnerable.
- Team work is much more important than the sum of individuals
- It is the responsibility of the project manager to keep track of his teams. Since teamwork is
much more important than the sum of the individuals.
Boehm – Staffing Principles:
Boehm’s 5 principles to staffing for a software project.
24. Tutorials - Software Project Management
By Vinod Kumar
1) The principle of top talent: Use better and fewer people.
2) The principle of job matching: Fit the tasks to the skills and motivation of the people
available.
3) The principle of career progression: Helping those people to self-actualize (Self-
actualization means- acceptance and realism. It’s a psychology concept), which makes an
organization in a progressive and best in long run.
4) The principle of team balance: Select people who will complement and synchronize with
one another.
5) The principle of phase-out: Giving a misfit on the team doesn’t benefit anyone.
In general, staffing is achieved by these common methods:
– If people are already available with required skill set, just take them
– If people are already available but do not have the required skills, re-train them
– If people are not available, recruit trained people
– If you are not able to recruit skilled people, recruit and train people
Staffing of key personnel is very important:
- Project Manager
- Software Architect
Important Project Manager Skills:
- Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the
right job seems obvious but is surprisingly hard to achieve.
- Customer-interface skill. Avoiding adversarial relationships among stake-holders is a
prerequisite for success.
- Decision-making skill. The jillion books written about management have failed to provide a
clear definition of this attribute. We all know a good leader when we run into one, and decision-
making skill seems obvious despite its intangible definition (intangible means – not definite, it is
hard to define and it has not having a physical presence).
- Team-building skill. Teamwork requires that a manager establish trust, motivate progress,
exploit eccentric prima donnas, transition average people into top performers, eliminate misfits,
and consolidate diverse opinions into a team direction.
- Selling skill. In theoretical, Successful project managers must sell all stakeholders (including
themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status
quo in the face of resistance, and sell achievements against objectives. In practice, selling
requires continuous negotiation, compromise, and empathy (empathy means- sympathy, to
recognize feelings, thoughts, attitudes of another).
Important Software Architect Skills:
• Technical Skills: the most important skills for an architect. These must include skills in both,
the problem domain and the solution domain
25. Tutorials - Software Project Management
By Vinod Kumar
• People Management Skills: must ensure that all people understand and implement the
architecture in exactly the way he has conceptualized it. This calls for a lot of people
management skills and patience.
• Role Model: must be a role model for the software engineers – they would emulate all good
(and also all bad !) things that the architect does
Improving Automation Through Software Environments
The following are the some of the configuration management environments which provide the
foundation for executing and implementing the process:
Planning tools, Quality assurance and analysis tools, Test tools, and User interfaces provide
crucial automation support for evolving the software engineering artifacts.
Round-trip engineering: is a term used to describe the key capability of environments that
support iterative development.
Forward engineering: is the automation of one engineering artifact from another, more abstract
representation. Ex: compilers and linkers
Reverse engineering: is the generation of modification of more abstract representation from an
existing artifact. Ex: creating visual design model from a source code.
Achieving Required Quality:
Key elements that improve overall software quality include the following:
- Focusing on powerful requirements and critical use case early in the life cycle
- Focusing on requirements completeness and traceability late in the life cycle
- Focusing throughout the life cycle on a balance between requirements evolution, design
evolution, and plan evolution
- Using metrics and indicators to measure the progress and quality of architecture as it evolves
from high-level prototype into a fully biddable product
- Providing integrated life-cycle environments that support early and continuous configuration
control, change management, rigorous design methods, document automation, and regression test
automation
- Using visual modeling and higher level languages that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
- Early and continuous close look into performance issues through demonstration-based
evaluations
In order to evaluate the performance the following sequence of events are necessary,
1) Project inception
2) Initial design review
3) Mid-life-cycle design review
4) Integration and test
26. Tutorials - Software Project Management
By Vinod Kumar
ACHIEVING REQUIRED QUALITY
General quality improvement with a modern process:
QUALITY DRIVER CONVENTIONAL MODERN ITERATIVE
PROCESS PROCESSES
Requirements Discovered late Resolved early
Misunderstanding
Development risk Unknown until late Understood and resolved early
Commercial Mostly unavailable Still a quality driver, but tradeoffs
components must be resolved early in the life cycle
Change management Late in the life cycle, Early in the life cycle, straight
chaotic and malignant forward and benign
Design errors Discovered late Resolved early
Automation Mostly error-prone manual Mostly automated, error-free
procedures evolution of artifacts
Resource adequacy Unpredictable Predictable
Schedules Over constrained Tunable to quality, performance, and
technology
Target performance Paper-based analysis or Executing prototypes, early
separate simulation performance feedback, quantitative
understanding
Software process rigor Document-based Manage, measured, and tool-
supported
CHRONOLOGY OF EVENTS IN PERFORMANCE ASSESSMENT
• Project inception. The proposed design was asserted to be low risk with adequate
performance margin.
•
• Initial design review. Optimistic assessments of adequate design margin were based
mostly on paper analysis or rough simulation of the critical threads. In most cases, the
actual application algorithms and database sizes were fairly well understood. However,
the infrastructure – including the operating system overhead, the database management
overhead, and the inter-process and network communication overhead – and all the
secondary threads were typically misunderstood.
• Mid-life cycle design review. The assessments started whittling away at the margin, as
early benchmarks and initial tests began exposing the optimum inherent in earlier
estimates.
• Integration and test. Serious performance problems were uncovered, necessitating
fundamental changes in the architecture. The underlying infrastructure was usually the
scapegoat, but the real culprit was immature use of the infrastructure, immature
architectural solutions, or poorly understood early design trade-offs.
27. Tutorials - Software Project Management
By Vinod Kumar
PEER INSPECTIONS: A PRAGMATIC VIEW:
Pragmatic means – deals practically rather than theoretically.
Aim of peer inspection:
To detect and remove the defects in the field of software project development.
Improve software quality always remains a key challenge.
To address this challenge, a formal peer inspection has emerged for software development.
Improving software quality remains a key challenge.
Software development formal peer inspection has emerged as an effective approach to
address this challenge.
Software peer inspection aims at detecting and removing software development defects
efficiently and early while defects are less expensive to correct.
• Transitioning engineering information from one artifact set to another, thereby
assessing the consistency, feasibility, understandability, and technology constraints
inherent in the engineering artifacts. Consistency means – to achieve a level of
performance without varying in software quality over time.
• Major milestone demonstrations that force the artifacts to be assessed against tangible
in the context of relevant use cases.
• Environment tools like compiler, debugger, analyzers, automated test suits that ensure
representation rigor, consistency, completeness, and change control.
• Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria, and
requirements compliance.
• Change management metrics for objective insight
USEFUL GUIDELINES
Keep the review team small
Find problems during reviews, but don't try to solve them
Limit review meetings to about two hours.
Require advance preparation
Architectural issues exposed through rigorous engineering activities as following:
Critical component deserves to be inspected by several people, preferably those who have a
stake in its quality, performance, or feature set.
An inspection focused on resolving an existing issue can be an effective way to determine
cause or arrive at a resolution once the cause is understood.
28. Tutorials - Software Project Management
By Vinod Kumar
Random human inspections tend to degenerate into comments on style and first-order semantic
issues. They rarely result in the discovery of real performance bottlenecks, serious control issues
(such as deadlocks, races, or resource contention), or architectural weakness (such as flaws in
scalability, reliability, or interoperability).
Quality assurance is everyone’s responsibility and should be integral to almost all process
activities instead of a separate discipline performed by quality assurance specialists.
Evaluating and assessing the quality of the evolving engineering baselines should be the job of
an engineering team that is independent of the architecture and development team.
Their life-cycle assessment of the evolving artifacts would typically include change
management, trend analysis, and testing, as well as inspection.
The Old Way And The New
- Over the past two decades software development is a re-engineering process. Now it is replaced
by advanced software engineering technologies.
- This transition is was motivated by the unsatisfactory demand for the software
and reduced cost.
The Principles Of Conventional Software Engineering
Based on many years of software development experience, the software industry proposed so
many principles (nearly 201 by – Davis’s). Of which Davis’s top 30 principles are:
1) Make quality #1: Quality must be quantified and mechanisms put into place to motivate its
achievement.
2) High-quality software is possible: In order to improve the quality of the product we need to
involving the customer, select the prototyping, simplifying design, conducting inspections, and
hiring the best people.
3) Give products to customers early: No matter how hard you try to learn user’s needs during
the requirements phase, the most effective way to determine real needs is to give users a product
and let them play with it.
4) Determine the problem before writing the requirements: Whenever a problem is raised
most engineers provide a solution. Before we try to solve a problem, be sure to explore all the
alternatives and don’t be blinded by the understandable solution.
5) Evaluate design alternatives: After the requirements are greed upon, we must examine a
variety of architectures and algorithms and choose the one which is not used earlier.
6) Use an appropriate process model: For every project, there are so many prototypes (process
models). So select the best one that is exactly suitable to our project.
29. Tutorials - Software Project Management
By Vinod Kumar
7) Use different languages for different phases: Our industry’s main aim is to provide simple
solutions to complex problems. In order to accomplish this goal choose different languages for
different modules/phases if required.
8) Minimize intellectual distance: We have to design the structure of software is as close as
possible to the real-world structure.
9) Put techniques before tools: An un disciplined software engineer with a tool becomes a
dangerous, undisciplined software engineer.
10) Get it right before you make it faster: It is very easy to make a working program run faster
than it is to make a fast program work. Don’t worry about optimization during initial coding.
11) Inspect the code: Examine the detailed design and code is a much better way to find the
errors than testing.
12) Good management is more important than good technology
13) People are the key to success: Highly skilled people with appropriate experience, talent,
and training are keys. The right people with insufficient tools, languages, and process will
succeed.
14) Follow with care: Everybody is doing something but does not make it right for you. It may
be right, but you must carefully assess its applicability to your environment.
15) Take responsibility: When a bridge collapses we ask “what did the engineer do wrong?”.
Similarly if the software fails, we ask the same. So the fact is in every engineering discipline, the
best methods can be used to produce poor results and the most out of date methods to produce
stylish design.
16) Understand the customer’s priorities. It is possible the customer would tolerate 90% of the
functionality delivered late if they could have 10% of it on time.
17) The more they see, the more they need. The more functionality (or performance) you
provide a user, the more functionality (or performance) the user wants.
18) Plan to throw one away .One of the most important critical success factors is whether or not
a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms
rarely work the first time.
19) Design for change. The architectures, components, and specification techniques you use
must accommodate change.
20) Design without documentation is not design. I have often heard software engineers say, “I
have finished the design. All that is left is the documentation.”
21. Use tools, but be realistic. Software tools make their users more efficient.
30. Tutorials - Software Project Management
By Vinod Kumar
22. Avoid tricks. Many programmers love to create programs with tricks constructs that perform
a function correctly, but in an obscure way. Show the world how smart you are by avoiding
tricky code.
23. Encapsulate. Information-hiding is a simple, proven concept that results in software that is
easier to test and much easier to maintain.
24. Use coupling and cohesion. Coupling and cohesion are the best ways to measure software’s
inherent maintainability and adaptability.
25. Use the McCabe complexity measure. Although there are many metrics available to report
the inherent complexity of software, none is as intuitive and easy to use as Tom McCabe’s.
26. Don’t test your own software. Software developers should never be the primary testers of
their own software.
27. Analyze causes for errors. It is far more cost-effective to reduce the effect of an error by
preventing it than it is to find and fix it. One way to do this is to analyze the causes of errors as
they are detected.
28. Realize that software’s entropy increases. Any software system that undergoes continuous
change will grow in complexity and become more and more disorganized.
29. People and time are not interchangeable. Measuring a project solely by person-months
makes little sense.
30) Expert excellence. Your employees will do much better if you have high expectations for
them.
The Principles of Modern Software Management:
Modern software development produces the architecture first and then the complete length.
Requirements and design issues are detected and resolved earlier in the life cycle. The following
are the principles:-
1. Base the process on architecture first approach.
2. Establish on iterative life cycle.
3. Employee component based development, if possible.
4. Establish a change management environment.
5. Enhance the freedom to change through various tools and techniques.
6. Capture the design in a model based notation.
7. Increment the process for quality and progress.
8. Uses demonstrate based approach to access the artifacts.
9. Establish an economically scalable and configurable process.
These principles will result in less scrap and rework with a great emphasis on early life cycle
engineering. It also results in balanced expenditure of the resources across the various work
flows in a development process. An example of modern software development is RUP (Rational
Unified Process). Rational is the name given to the software developed by IBM. It is a model
31. Tutorials - Software Project Management
By Vinod Kumar
driven approach. It supports the iterative development and is based upon an the modern software
development principles.
Life cycle of RUP is divided into 4 phases:
1. Inception
2. Elaboration
3. Construction
4. Transition
Inception
– It includes the definition and assessment of the project.
Elaboration
– It includes the synthesis, demonstration and assessment of the architecture base line.
Construction
– It includes the development, demonstration and assessment of various increments in a life
cycle.
Transition
– It includes the usability and development.
Life cycle software artifacts are divided into 5 sets:
1. Requirements
2. Design
3. Implementation
4. Development
5. Management
32. Tutorials - Software Project Management
By Vinod Kumar
It’s very important that expenditure allocation to activities on a life cycle process.
Activities Conventional Modern
1. Management 5% 10%
2. Requirement 5% 10%
3. Design 10% 15%
4. Implementation 30% 25%
5. Testing 40% 25%
6. Development 5% 5%
7. Environment 5% 10%
100% 100%
The Principles of Modern Software Management
1) Base the process on an architecture-first approach: (Central design element)
- Design and integration first, then production and test
2) Establish an iterative life-cycle process: (The risk management element)
- Risk control through ever-increasing function, performance, quality. With today’s sophisticated
systems, it is not possible to define the entire problem, design the entire solution, build the
software, then test the end product in sequence. Instead, and iterative process that refines the
problem understanding, an effective solution, and an effective plan over several iterations
encourages balanced treatment of all stakeholder objectives. Major risks must be addressed early
to increase predictability and avoid expensive downstream scrap and rework.
3) Transition design methods to emphasize component-based development: (The technology
element) moving from LOC mentally to component-based mentally is necessary to reduce the
amount of human-generated source code and custom development. A component is a cohesive
set of preexisting lines of code, either in source or executable format, with a defined interface
and behavior.
4) Establish a change management environment: (The control element)
33. Tutorials - Software Project Management
By Vinod Kumar
- Metrics, trends, process instrumentation. The dynamics of iterative development, include
concurrent workflows by different teams working on shared artifacts, necessitates objectively
controlled baseline.
5) Enhance change freedom through tools that support round-trip engineering: (The automation
element)
- Complementary tools, integrated environment. Round-trip engineering is the environment
support necessary to automate and synchronize engineering information in different formats.
Change freedom is necessary in an iterative process.
6) Capture design artifacts in rigorous, model-based notation:
- A model-based approach supports the evolution of semantically rich graphical and textual
design notations.
- Visual modeling with rigorous notations and formal machine- process able language provides
more objective measures than the traditional approach of human review and inspection of ad hoc
design representations in paper doc.
7) Instrument the process for objective quality control and progress assessment:
- Life-cycle assessment of the progress and quality of all intermediate products must be
integrated into the process.
- The best assessment mechanisms are well-defined measures derived directly from the evolving
engineering artifacts and integrated into all activities and teams.
8) Use a demonstration-based approach to assess intermediate artifacts:
Transitioning from whether the artifact is an early prototype, baseline architecture, or a beta
capability into an executable demonstration of relevant provides more tangible understanding of
the design tradeoffs, early integration and earlier elimination of architectural defects.
9) Plan intermediate releases in groups of usage scenarios with evolving levels of detail:
10) Establish a configurable process that economically scalable:
No single process is suitable for all software developments. The process must ensure that there is
economy of scale and ROI.