The document discusses several aspects of software project management including risk management, managing people, and teamwork. It describes the risk management process of identifying, analyzing, planning for, and monitoring risks. Examples of different types of project, product, and business risks are provided. The document also discusses the importance of people management in projects and different personality types and motivations that managers should consider. Motivation factors like an individual's needs hierarchy and creating a balanced environment are addressed.
The document discusses quality management in software development. It covers topics such as software quality, standards, reviews, quality management in agile development, and software measurement. Specifically, it describes that quality management is concerned with ensuring a required level of quality is achieved. It establishes organizational processes and standards to lead to high quality software. Quality management also involves applying specific quality processes and checking that planned processes are followed.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
This document discusses service-oriented software engineering and related topics. It covers service-oriented architectures, RESTful services, service engineering, and service composition. Key points include:
- Service-oriented architectures allow distributed systems to be developed where components are independent services. Standard protocols support service communication and information exchange.
- RESTful services provide a simpler alternative to SOAP/WSDL for implementing web services, using resources and standard HTTP methods like GET and POST.
- Service engineering is the process of developing reusable services, including identifying service candidates, designing service interfaces, and implementing and deploying services.
- Identifying appropriate service candidates involves understanding business processes and entities that could be supported by reusable services.
This document discusses software evolution and maintenance. It covers topics like the inevitability of software change, legacy systems, and evolution processes. Software evolution involves implementing changes to existing systems to address new requirements, errors, or other issues. Most software budgets are spent evolving existing systems rather than developing new ones. Legacy systems rely on outdated technologies and can be difficult and expensive to change or replace. Effective evolution processes are needed to manage software changes over a system's lifetime.
This chapter introduces the key topics of the document, which are professional software development, software engineering ethics, and case studies. It defines software engineering as an engineering discipline concerned with all aspects of professional software development. It discusses the importance of software to economies and how software costs are a major factor. It also introduces common software engineering processes like specification, development, validation, and evolution.
Component-based software engineering (CBSE) is an approach that relies on reusable software components. It emerged due to limitations of object-oriented development in supporting effective reuse. CBSE uses independent and interchangeable components that communicate through well-defined interfaces. Middleware provides support for component interoperability. CBSE processes involve both developing components for reuse and developing systems using existing reusable components.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
The document discusses quality management in software development. It covers topics such as software quality, standards, reviews, quality management in agile development, and software measurement. Specifically, it describes that quality management is concerned with ensuring a required level of quality is achieved. It establishes organizational processes and standards to lead to high quality software. Quality management also involves applying specific quality processes and checking that planned processes are followed.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
This document discusses service-oriented software engineering and related topics. It covers service-oriented architectures, RESTful services, service engineering, and service composition. Key points include:
- Service-oriented architectures allow distributed systems to be developed where components are independent services. Standard protocols support service communication and information exchange.
- RESTful services provide a simpler alternative to SOAP/WSDL for implementing web services, using resources and standard HTTP methods like GET and POST.
- Service engineering is the process of developing reusable services, including identifying service candidates, designing service interfaces, and implementing and deploying services.
- Identifying appropriate service candidates involves understanding business processes and entities that could be supported by reusable services.
This document discusses software evolution and maintenance. It covers topics like the inevitability of software change, legacy systems, and evolution processes. Software evolution involves implementing changes to existing systems to address new requirements, errors, or other issues. Most software budgets are spent evolving existing systems rather than developing new ones. Legacy systems rely on outdated technologies and can be difficult and expensive to change or replace. Effective evolution processes are needed to manage software changes over a system's lifetime.
This chapter introduces the key topics of the document, which are professional software development, software engineering ethics, and case studies. It defines software engineering as an engineering discipline concerned with all aspects of professional software development. It discusses the importance of software to economies and how software costs are a major factor. It also introduces common software engineering processes like specification, development, validation, and evolution.
Component-based software engineering (CBSE) is an approach that relies on reusable software components. It emerged due to limitations of object-oriented development in supporting effective reuse. CBSE uses independent and interchangeable components that communicate through well-defined interfaces. Middleware provides support for component interoperability. CBSE processes involve both developing components for reuse and developing systems using existing reusable components.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses system modeling and different types of models used in system modeling. It covers context models, interaction models, structural models, behavioral models, and model-driven engineering. Some key points include:
- System modeling involves developing abstract models of a system from different perspectives or views. Models are often developed using the Unified Modeling Language (UML).
- Common model types include use case diagrams, sequence diagrams, class diagrams, state diagrams, and activity diagrams.
- Structural models show the organization and structure of a system. Behavioral models show the system's dynamic behavior and responses to events.
- Model-driven engineering is an approach where models rather than code are the primary outputs and code is generated
The document discusses architectural design and various architectural concepts. It covers topics like architectural design decisions, architectural views using different models, common architectural patterns like MVC and layered architectures, application architectures, and how architectural design is concerned with organizing a software system and identifying its main structural components and relationships.
The document discusses requirements engineering processes. It covers topics such as functional and non-functional requirements, requirements elicitation, specification, validation and change. Requirements elicitation involves discovering requirements through interviews, ethnography and scenarios/stories with stakeholders. Requirements must be specified precisely and consistently. Non-functional requirements constrain the system and can be more critical than functional requirements. An iterative spiral process is used involving elicitation, analysis, validation and specification.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
This document provides an introduction and overview of key topics in software engineering. It discusses what software engineering is, the importance and costs of software development, different types of software projects and applications, and issues like complexity, security and scale that affect software. It also introduces software engineering processes, methods, and ethics. Common questions about the field are addressed. The document is the first chapter of a book on software engineering.
This document discusses systems of systems and complexity. It begins by defining systems of systems and providing examples. Key characteristics of systems of systems include operational and managerial independence of elements, and evolutionary development. The document then covers sources of complexity, including technical, managerial and governance complexity. It discusses how reductionism has traditionally been used to manage complexity in engineering but has limitations for large systems of systems.
This document discusses topics related to software design and implementation, including object-oriented design using UML, design patterns, and implementation issues. It provides details on the design and implementation process for a weather station system, including identifying system objects and classes, developing design models like sequence and state diagrams, and specifying interfaces. Design patterns are also introduced as a way to reuse solutions to common problems.
The document discusses reliability engineering and fault tolerance. It covers topics like availability, reliability requirements, fault-tolerant architectures, and reliability measurement. It defines key terms like faults, errors, and failures. It also describes techniques for achieving reliability like fault avoidance, fault detection, and fault tolerance. Specific architectures discussed include redundant systems and protection systems that can take emergency action if failures occur.
This document discusses various topics related to distributed software engineering including distributed systems, client-server computing, architectural patterns for distributed systems, and software as a service. It covers key characteristics of distributed systems like resource sharing, openness, concurrency, scalability, and fault tolerance. Some important design issues for distributed systems are also outlined such as transparency, openness, scalability, security, quality of service, and failure management. Common models of interaction in distributed systems including remote procedure calls and message passing are described. The roles of middleware and common architectural patterns like client-server, multi-tier, and distributed components are summarized.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
This document provides an overview of topics in chapter 13 on security engineering. It discusses security and dependability, security dimensions of confidentiality, integrity and availability. It also outlines different security levels including infrastructure, application and operational security. Key aspects of security engineering are discussed such as secure system design, security testing and assurance. Security terminology and examples are provided. The relationship between security and dependability factors like reliability, availability, safety and resilience is examined. The document also covers security in organizations and the role of security policies.
This document discusses component-based software engineering (CBSE). It covers topics like components and component models, CBSE processes, and component composition. The key points are:
- CBSE relies on reusable software components with well-defined interfaces to improve reuse. Components are more abstract than classes.
- Essentials of CBSE include independent, interface-specified components; standards for integration; and middleware for interoperability.
- CBSE is based on principles like independence, hidden implementations, and replaceability through maintained interfaces.
This document discusses safety engineering for systems that contain software. It covers topics like safety-critical systems, safety requirements, and safety engineering processes. Safety is defined as a system's ability to operate normally and abnormally without harm. For safety-critical systems like aircraft or medical devices, software is often used for control and monitoring, so software safety is important. Hazard identification, risk assessment, and specifying safety requirements to mitigate risks are key parts of the safety engineering process. The goal is to design systems where failures cannot cause injury, death or environmental damage.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
The document discusses project planning, including topics like software pricing, plan-driven development, project scheduling, and agile planning. It covers the different stages of planning, from initial proposals to ongoing development. Project planning involves breaking work into parts, anticipating problems, and communicating the plan. Regular updates allow the plan to reflect new information and changes throughout the project.
The document discusses various topics related to software testing, including different types of testing (unit testing, component testing, system testing), test-driven development, and goals and processes for validation and defect testing. It provides examples and guidelines for testing individual components, interfaces, and integrated systems to discover errors and ensure software meets requirements.
The document discusses dependability in systems. It covers topics like dependability properties, sociotechnical systems, redundancy and diversity, and dependable processes. Dependability reflects how trustworthy a system is and includes attributes like reliability, availability, and security. Dependability is important because system failures can have widespread impacts. Both hardware and software failures and human errors can cause systems to fail. Techniques like redundancy, diversity, and formal methods can help improve dependability. Regulation is also discussed as many critical systems require approval from regulators.
Chapter 22 – Project Management
04/12/2014
Chapter 22 Project management
1
Topics covered
Risk management
Managing people
Teamwork
04/12/2014
Chapter 22 Project management
2
Software project management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.
04/12/2014
Chapter 22 Project management
3
Success criteria
Deliver the software to the customer at the agreed time.
Keep overall costs within budget.
Deliver software that meets the customer’s expectations.
Maintain a coherent and well-functioning development team.
04/12/2014
Chapter 22 Project management
4
Software management distinctions
The product is intangible.
Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed.
Many software projects are 'one-off' projects.
Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems.
Software processes are variable and organization specific.
We still cannot reliably predict when a particular software process is likely to lead to development problems.
04/12/2014
Chapter 22 Project management
5
Factors influencing project management
Company size
Software customers
Software size
Software type
Organizational culture
Software development processes
These factors mean that project managers in different organizations may work in quite different ways.
04/12/2014
Chapter 22 Project management
6
Universal management activities
Project planning
Project managers are responsible for planning. estimating and scheduling project development and assigning people to tasks.
Covered in Chapter 23.
Risk management
Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise.
People management
Project managers have to choose people for their team and establish ways of working that leads to effective team performance.
04/12/2014
Chapter 22 Project management
7
Management activities
Reporting
Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software.
Proposal writing
The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out.
04/12/2014
Chapter 22 Project management
8
Risk management
04/12/2014
Chapter 22 Project management
9
Risk management
Risk management is concerned with identifying risks and drawing up plans to mini ...
This document discusses project management and risk management. It covers topics such as managing people, teamwork, risk identification, analysis, planning, monitoring, and strategies to manage common project risks like staff turnover, requirements changes, and underestimating timelines. The key aspects of software project management are planning, reporting, risk assessment, and people management to deliver software on schedule, within budget, and that meets customer expectations.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses system modeling and different types of models used in system modeling. It covers context models, interaction models, structural models, behavioral models, and model-driven engineering. Some key points include:
- System modeling involves developing abstract models of a system from different perspectives or views. Models are often developed using the Unified Modeling Language (UML).
- Common model types include use case diagrams, sequence diagrams, class diagrams, state diagrams, and activity diagrams.
- Structural models show the organization and structure of a system. Behavioral models show the system's dynamic behavior and responses to events.
- Model-driven engineering is an approach where models rather than code are the primary outputs and code is generated
The document discusses architectural design and various architectural concepts. It covers topics like architectural design decisions, architectural views using different models, common architectural patterns like MVC and layered architectures, application architectures, and how architectural design is concerned with organizing a software system and identifying its main structural components and relationships.
The document discusses requirements engineering processes. It covers topics such as functional and non-functional requirements, requirements elicitation, specification, validation and change. Requirements elicitation involves discovering requirements through interviews, ethnography and scenarios/stories with stakeholders. Requirements must be specified precisely and consistently. Non-functional requirements constrain the system and can be more critical than functional requirements. An iterative spiral process is used involving elicitation, analysis, validation and specification.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
This document provides an introduction and overview of key topics in software engineering. It discusses what software engineering is, the importance and costs of software development, different types of software projects and applications, and issues like complexity, security and scale that affect software. It also introduces software engineering processes, methods, and ethics. Common questions about the field are addressed. The document is the first chapter of a book on software engineering.
This document discusses systems of systems and complexity. It begins by defining systems of systems and providing examples. Key characteristics of systems of systems include operational and managerial independence of elements, and evolutionary development. The document then covers sources of complexity, including technical, managerial and governance complexity. It discusses how reductionism has traditionally been used to manage complexity in engineering but has limitations for large systems of systems.
This document discusses topics related to software design and implementation, including object-oriented design using UML, design patterns, and implementation issues. It provides details on the design and implementation process for a weather station system, including identifying system objects and classes, developing design models like sequence and state diagrams, and specifying interfaces. Design patterns are also introduced as a way to reuse solutions to common problems.
The document discusses reliability engineering and fault tolerance. It covers topics like availability, reliability requirements, fault-tolerant architectures, and reliability measurement. It defines key terms like faults, errors, and failures. It also describes techniques for achieving reliability like fault avoidance, fault detection, and fault tolerance. Specific architectures discussed include redundant systems and protection systems that can take emergency action if failures occur.
This document discusses various topics related to distributed software engineering including distributed systems, client-server computing, architectural patterns for distributed systems, and software as a service. It covers key characteristics of distributed systems like resource sharing, openness, concurrency, scalability, and fault tolerance. Some important design issues for distributed systems are also outlined such as transparency, openness, scalability, security, quality of service, and failure management. Common models of interaction in distributed systems including remote procedure calls and message passing are described. The roles of middleware and common architectural patterns like client-server, multi-tier, and distributed components are summarized.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
This document provides an overview of topics in chapter 13 on security engineering. It discusses security and dependability, security dimensions of confidentiality, integrity and availability. It also outlines different security levels including infrastructure, application and operational security. Key aspects of security engineering are discussed such as secure system design, security testing and assurance. Security terminology and examples are provided. The relationship between security and dependability factors like reliability, availability, safety and resilience is examined. The document also covers security in organizations and the role of security policies.
This document discusses component-based software engineering (CBSE). It covers topics like components and component models, CBSE processes, and component composition. The key points are:
- CBSE relies on reusable software components with well-defined interfaces to improve reuse. Components are more abstract than classes.
- Essentials of CBSE include independent, interface-specified components; standards for integration; and middleware for interoperability.
- CBSE is based on principles like independence, hidden implementations, and replaceability through maintained interfaces.
This document discusses safety engineering for systems that contain software. It covers topics like safety-critical systems, safety requirements, and safety engineering processes. Safety is defined as a system's ability to operate normally and abnormally without harm. For safety-critical systems like aircraft or medical devices, software is often used for control and monitoring, so software safety is important. Hazard identification, risk assessment, and specifying safety requirements to mitigate risks are key parts of the safety engineering process. The goal is to design systems where failures cannot cause injury, death or environmental damage.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
The document discusses project planning, including topics like software pricing, plan-driven development, project scheduling, and agile planning. It covers the different stages of planning, from initial proposals to ongoing development. Project planning involves breaking work into parts, anticipating problems, and communicating the plan. Regular updates allow the plan to reflect new information and changes throughout the project.
The document discusses various topics related to software testing, including different types of testing (unit testing, component testing, system testing), test-driven development, and goals and processes for validation and defect testing. It provides examples and guidelines for testing individual components, interfaces, and integrated systems to discover errors and ensure software meets requirements.
The document discusses dependability in systems. It covers topics like dependability properties, sociotechnical systems, redundancy and diversity, and dependable processes. Dependability reflects how trustworthy a system is and includes attributes like reliability, availability, and security. Dependability is important because system failures can have widespread impacts. Both hardware and software failures and human errors can cause systems to fail. Techniques like redundancy, diversity, and formal methods can help improve dependability. Regulation is also discussed as many critical systems require approval from regulators.
Chapter 22 – Project Management
04/12/2014
Chapter 22 Project management
1
Topics covered
Risk management
Managing people
Teamwork
04/12/2014
Chapter 22 Project management
2
Software project management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.
04/12/2014
Chapter 22 Project management
3
Success criteria
Deliver the software to the customer at the agreed time.
Keep overall costs within budget.
Deliver software that meets the customer’s expectations.
Maintain a coherent and well-functioning development team.
04/12/2014
Chapter 22 Project management
4
Software management distinctions
The product is intangible.
Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed.
Many software projects are 'one-off' projects.
Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems.
Software processes are variable and organization specific.
We still cannot reliably predict when a particular software process is likely to lead to development problems.
04/12/2014
Chapter 22 Project management
5
Factors influencing project management
Company size
Software customers
Software size
Software type
Organizational culture
Software development processes
These factors mean that project managers in different organizations may work in quite different ways.
04/12/2014
Chapter 22 Project management
6
Universal management activities
Project planning
Project managers are responsible for planning. estimating and scheduling project development and assigning people to tasks.
Covered in Chapter 23.
Risk management
Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise.
People management
Project managers have to choose people for their team and establish ways of working that leads to effective team performance.
04/12/2014
Chapter 22 Project management
7
Management activities
Reporting
Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software.
Proposal writing
The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out.
04/12/2014
Chapter 22 Project management
8
Risk management
04/12/2014
Chapter 22 Project management
9
Risk management
Risk management is concerned with identifying risks and drawing up plans to mini ...
This document discusses project management and risk management. It covers topics such as managing people, teamwork, risk identification, analysis, planning, monitoring, and strategies to manage common project risks like staff turnover, requirements changes, and underestimating timelines. The key aspects of software project management are planning, reporting, risk assessment, and people management to deliver software on schedule, within budget, and that meets customer expectations.
Alice is a project manager leading a team developing assistive technology. She notices one team member, Dorothy, has lost motivation and interest in the project. After speaking with Dorothy, Alice learns Dorothy is worried her hardware skills are not being utilized and she may have trouble finding future work. Alice understands the importance of team cohesion and motivation. She works to create cohesion through involving the team in product planning and design, and arranging informal monthly lunches for the team to bond.
This document discusses key aspects of project management for software development projects. It covers topics like risk management, managing people, and teamwork. For risk management, it describes identifying, analyzing, planning for, and monitoring risks. It provides examples of common project, product, and business risks. For managing people, it discusses motivating individuals and teams. It also covers the importance of teamwork and creating cohesive teams. The overall summary is that project management is important for delivering software on time and on budget by addressing risks, motivating people, and fostering effective teamwork.
The document discusses software project management and risk management. It identifies several types of risks that can affect software projects, including technology risks, people risks, organizational risks, and requirements risks. It also describes the key aspects of risk management: risk identification, analysis, planning, monitoring, and control. Effective risk management strategies include avoidance, minimization, and contingency planning to address risks that could impact a project's schedule, budget, or quality. Regular risk assessment is needed to determine if risks have increased or decreased over time.
This document discusses software project risk management. It begins by defining risk management as identifying risks that could affect a software project and developing plans to minimize their impact. It then covers different types of risks like project risks, product risks, and business risks. Examples of each risk type are provided. The risk management process is outlined as risk identification, analysis, planning, and monitoring. Methods for identifying risks like checklists are described. Risk analysis involves assessing the probability and potential consequences of each risk. Risk planning develops strategies to avoid, minimize, or mitigate risks. Contingency plans are suggested to address risks that do occur.
This chapter discusses project management topics such as risk management, managing people, and teamwork. It explains that project management ensures software is delivered on time, on budget, and according to requirements. Success requires delivering software to meet the customer's expectations while keeping the development team happy. The document then covers distinguishing features of software project management, management activities like planning and reporting, and approaches to risk management, people management, and motivating teams.
Risk management involves identifying potential risks to a project, analyzing their likelihood and impact, and developing plans to mitigate negative risks. Some key risks include staff turnover, requirements changes, and underestimating the time or resources needed. It is important to identify risks early, communicate about them, assign ownership, prioritize risks, and regularly monitor risks and mitigation strategies. Effective risk management can help promote the success of software projects by focusing resources and preventing potential problems.
This document provides an overview of the CS414 course on Computer Center Management. It discusses the instructor, textbooks, assessment breakdown, course objectives covering various topics in IT management, and a course plan outline. It also covers key concepts around project management including developing a software development plan, work breakdown structure, and risks. The overall summary is that this document outlines the structure and content of a course on Computer Center and IT project management.
This document provides an overview of the CS414 course on Computer Center Management. It discusses the instructor, textbooks, assessment breakdown, course objectives covering various topics in IT management, and a course plan outline. It also covers key concepts like the importance of IT in business, differences between data and information, project management principles and activities, developing a software development plan including work breakdown structures, and important risks to consider in project planning. The overall document serves as an introduction to the course content and expectations.
This document provides an overview of the CS414 course on Computer Center Management. It discusses the instructor, textbooks, assessment breakdown, course objectives covering various topics in IT management, and a course plan outline. It also covers key concepts like the importance of IT in business, differences between data and information, project management principles and activities, developing a software development plan including work breakdown structures, and important risks to consider in project planning. The overall summary is that this document outlines the structure and content to be covered in a course on Computer Center and IT project management.
This document discusses software project management. It covers topics such as project planning, scheduling, risk management, and staff allocation. Specifically, it describes the common management activities involved in software projects, including proposal writing, planning, costing, monitoring, and reporting. It emphasizes that project planning is an ongoing and iterative process from initial concept through system delivery. Risk management aims to identify potential risks and develop contingency plans to minimize their impact. The document provides examples of risk analysis and how to assess the probability and potential effects of different risks.
Project planning involves breaking down work into tasks assigned to team members, anticipating problems, and creating a project plan. The plan is used to communicate work and assess progress. Planning occurs at proposal, startup, and periodically throughout the project. At startup, more details are known and a plan is created for resource allocation. During development, the plan is regularly revised based on new information and experience. Agile planning uses iterative increments and flexible plans that can accommodate changing priorities and requirements.
This document discusses key topics in software project management including risk management, managing people, and teamwork. It covers the importance of project management for software projects to deliver on time and on budget. Success criteria for projects is outlined as delivering on time, within budget, meeting customer expectations, and having a satisfied team. Challenges include the intangible nature of software, one-off projects, and variable processes. The roles and activities of a project manager are summarized. Risk management processes like identification, analysis, planning and monitoring are explained. Managing people effectively through consistency, respect, inclusion and honesty is important. Different personality types and their motivations are noted. Factors that affect effective teamwork are the people, organization, and
How To Develop A Project Management PlanOrangescrum
For project managers, a successful outcome is always preceded by a well-prepared project management plan. A lot of effort is put into planning which helps you prepare a better Project Management Plan.
This document discusses software project management. It defines software as a collection of programs, instructions, key-value-character sets. It defines a project as a planned activity with specific objectives that is carried out over a predetermined time span in several phases with constrained resources. The key idea of software project management is planning, monitoring, and controlling software projects to ensure they satisfy real needs by identifying stakeholders and objectives. Proper management is important as surveys found most projects were late or over budget due to a lack of proven project management and risk management skills.
This document provides an overview of software project management. It discusses key topics like the project life cycle, stakeholders, tools and techniques, and challenges of software projects. Several studies found that 31-53% of IT projects were cancelled or over budget. Effective project managers balance scope, time and costs, use proven techniques, and have both technical and soft skills. Projects require defining goals, planning, execution, closure and evaluation to deliver value.
This document discusses software project planning and management. It covers topics like planning for both plan-driven and agile development, project scheduling, estimation techniques, and managing risks. It defines key aspects of project management like establishing a project plan, scheduling tasks, identifying and addressing risks, and managing people and teams. Estimation techniques discussed include experience-based and algorithmic modeling approaches. The document emphasizes the importance of project planning, tracking progress against plans, and adjusting plans based on new information or changes in risks and priorities.
The document discusses software development life cycles (SDLC) and agile development methods. It begins by defining SDLC and describing its typical stages. It then discusses various SDLC models like waterfall, iterative, V-model, and RAD. Next, it introduces agile development, describing its principles, comparing it to waterfall, and listing advantages and limitations. Finally, it discusses design patterns, their usage, and categories like creational patterns.
The document discusses configuration management (CM) which involves managing changing software systems through policies, processes and tools. Key CM activities include version management to track changes made by different developers, system building to create executable systems, change management to track requests for changes, and release management. CM is important for team projects and agile development where components change frequently. Version control systems are used to identify, store and control access to different component versions.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
This document provides an overview of systems of systems (SoS). It defines a SoS as a system containing two or more independently managed elements. Key characteristics of SoS include operational and managerial independence of elements. The document discusses challenges in engineering SoS due to lack of single control. It also describes common SoS development processes like conceptual design, system selection, and architectural design. Testing SoS is difficult as requirements may be undefined and constituent systems can change. The document advocates node and web architectures with collaboration incentives for SoS.
This document discusses systems engineering and the process of developing sociotechnical systems. It covers key topics like conceptual design, procurement, and the stages of systems engineering. Sociotechnical systems are complex and have emergent properties due to interactions between technical, human, and organizational factors. Success is difficult to define as stakeholders may have different views. Conceptual design develops an initial vision of the system purpose before detailed requirements. Procurement decisions involve choosing between custom development or commercial off-the-shelf systems.
The document discusses various topics related to software reuse, including application frameworks, software product lines, and application system reuse. It describes application frameworks as reusable architectures made up of abstract and concrete classes that are extended to create applications. Software product lines are families of applications with a common architecture that can be configured for different contexts. Application system reuse involves adapting generic application systems through configuration for specific customers. The document outlines several benefits and challenges to software reuse approaches.
This document discusses resilience engineering and designing resilient systems. It covers topics such as resilience, cybersecurity threats and controls, resilience planning, sociotechnical resilience, and resilient systems design. The key ideas are that resilience involves maintaining critical system services during disruptions, using defensive layers and redundancy to limit failures, and designing systems and processes to recognize, resist, recover from, and reinstate after problems.
The document discusses security engineering and covers topics such as security requirements, secure system design, security testing and assurance. It defines security engineering as tools, techniques and methods to develop systems that can resist malicious attacks. It also discusses security dimensions of confidentiality, integrity and availability. Finally, it provides an overview of the preliminary risk assessment process for defining security requirements.
This document provides an overview of safety engineering concepts and processes. It discusses safety-critical systems and the importance of considering software safety. Safety is defined as a system's ability to operate without danger of injury or damage. Key concepts covered include safety requirements, hazard identification and analysis, risk assessment and reduction strategies, and safety engineering processes. Safety-critical systems must be designed and developed following strict processes to ensure all hazards are identified and mitigated.
This document provides an overview of reliability engineering topics including software reliability, fault tolerance, and reliability requirements. It discusses key concepts such as availability, reliability, faults, errors and failures. It also describes different fault-tolerant system architectures and reliability metrics including probability of failure on demand, rate of occurrence of failures, and availability. Functional reliability requirements and examples are also presented relating to checking requirements, recovery requirements, redundancy requirements and development process requirements.
This chapter discusses dependable systems and covers topics like dependability properties, sociotechnical systems, redundancy and diversity, dependable processes, and formal methods for dependability. It defines dependability as reflecting a user's degree of trust in a system operating as expected without failure. Dependability encompasses attributes like reliability, availability, and security. Formal methods that use mathematical modeling can help reduce errors and improve dependability. Developing dependable systems also requires consideration of the sociotechnical context and dependable engineering processes.
The document discusses databases and database management systems (DBMS). It provides an example of a UNIVERSITY database to illustrate how data is structured and related. Key advantages of the database approach include controlling redundancy, restricting unauthorized access, and enforcing integrity constraints. The history of database applications is reviewed, from early hierarchical and network systems to current technologies like XML, no-sql, and using databases on the web.
Embedded machine learning-based road conditions and driving behavior monitoringIJECEIAES
Car accident rates have increased in recent years, resulting in losses in human lives, properties, and other financial costs. An embedded machine learning-based system is developed to address this critical issue. The system can monitor road conditions, detect driving patterns, and identify aggressive driving behaviors. The system is based on neural networks trained on a comprehensive dataset of driving events, driving styles, and road conditions. The system effectively detects potential risks and helps mitigate the frequency and impact of accidents. The primary goal is to ensure the safety of drivers and vehicles. Collecting data involved gathering information on three key road events: normal street and normal drive, speed bumps, circular yellow speed bumps, and three aggressive driving actions: sudden start, sudden stop, and sudden entry. The gathered data is processed and analyzed using a machine learning system designed for limited power and memory devices. The developed system resulted in 91.9% accuracy, 93.6% precision, and 92% recall. The achieved inference time on an Arduino Nano 33 BLE Sense with a 32-bit CPU running at 64 MHz is 34 ms and requires 2.6 kB peak RAM and 139.9 kB program flash memory, making it suitable for resource-constrained embedded systems.
Discover the latest insights on Data Driven Maintenance with our comprehensive webinar presentation. Learn about traditional maintenance challenges, the right approach to utilizing data, and the benefits of adopting a Data Driven Maintenance strategy. Explore real-world examples, industry best practices, and innovative solutions like FMECA and the D3M model. This presentation, led by expert Jules Oudmans, is essential for asset owners looking to optimize their maintenance processes and leverage digital technologies for improved efficiency and performance. Download now to stay ahead in the evolving maintenance landscape.
Electric vehicle and photovoltaic advanced roles in enhancing the financial p...IJECEIAES
Climate change's impact on the planet forced the United Nations and governments to promote green energies and electric transportation. The deployments of photovoltaic (PV) and electric vehicle (EV) systems gained stronger momentum due to their numerous advantages over fossil fuel types. The advantages go beyond sustainability to reach financial support and stability. The work in this paper introduces the hybrid system between PV and EV to support industrial and commercial plants. This paper covers the theoretical framework of the proposed hybrid system including the required equation to complete the cost analysis when PV and EV are present. In addition, the proposed design diagram which sets the priorities and requirements of the system is presented. The proposed approach allows setup to advance their power stability, especially during power outages. The presented information supports researchers and plant owners to complete the necessary analysis while promoting the deployment of clean energy. The result of a case study that represents a dairy milk farmer supports the theoretical works and highlights its advanced benefits to existing plants. The short return on investment of the proposed approach supports the paper's novelty approach for the sustainable electrical system. In addition, the proposed system allows for an isolated power setup without the need for a transmission line which enhances the safety of the electrical network
Null Bangalore | Pentesters Approach to AWS IAMDivyanshu
#Abstract:
- Learn more about the real-world methods for auditing AWS IAM (Identity and Access Management) as a pentester. So let us proceed with a brief discussion of IAM as well as some typical misconfigurations and their potential exploits in order to reinforce the understanding of IAM security best practices.
- Gain actionable insights into AWS IAM policies and roles, using hands on approach.
#Prerequisites:
- Basic understanding of AWS services and architecture
- Familiarity with cloud security concepts
- Experience using the AWS Management Console or AWS CLI.
- For hands on lab create account on [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
# Scenario Covered:
- Basics of IAM in AWS
- Implementing IAM Policies with Least Privilege to Manage S3 Bucket
- Objective: Create an S3 bucket with least privilege IAM policy and validate access.
- Steps:
- Create S3 bucket.
- Attach least privilege policy to IAM user.
- Validate access.
- Exploiting IAM PassRole Misconfiguration
-Allows a user to pass a specific IAM role to an AWS service (ec2), typically used for service access delegation. Then exploit PassRole Misconfiguration granting unauthorized access to sensitive resources.
- Objective: Demonstrate how a PassRole misconfiguration can grant unauthorized access.
- Steps:
- Allow user to pass IAM role to EC2.
- Exploit misconfiguration for unauthorized access.
- Access sensitive resources.
- Exploiting IAM AssumeRole Misconfiguration with Overly Permissive Role
- An overly permissive IAM role configuration can lead to privilege escalation by creating a role with administrative privileges and allow a user to assume this role.
- Objective: Show how overly permissive IAM roles can lead to privilege escalation.
- Steps:
- Create role with administrative privileges.
- Allow user to assume the role.
- Perform administrative actions.
- Differentiation between PassRole vs AssumeRole
Try at [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
Design and optimization of ion propulsion dronebjmsejournal
Electric propulsion technology is widely used in many kinds of vehicles in recent years, and aircrafts are no exception. Technically, UAVs are electrically propelled but tend to produce a significant amount of noise and vibrations. Ion propulsion technology for drones is a potential solution to this problem. Ion propulsion technology is proven to be feasible in the earth’s atmosphere. The study presented in this article shows the design of EHD thrusters and power supply for ion propulsion drones along with performance optimization of high-voltage power supply for endurance in earth’s atmosphere.
3. Software project management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software
development is always subject to budget and schedule
constraints that are set by the organisation developing
the software.
04/12/2014 Chapter 22 Project management 3
4. Success criteria
Deliver the software to the customer at the agreed time.
Keep overall costs within budget.
Deliver software that meets the customer’s expectations.
Maintain a coherent and well-functioning development
team.
04/12/2014 Chapter 22 Project management 4
5. Software management distinctions
The product is intangible.
Software cannot be seen or touched. Software project managers
cannot see progress by simply looking at the artefact that is
being constructed.
Many software projects are 'one-off' projects.
Large software projects are usually different in some ways from
previous projects. Even managers who have lots of previous
experience may find it difficult to anticipate problems.
Software processes are variable and organization
specific.
We still cannot reliably predict when a particular software
process is likely to lead to development problems.
04/12/2014 Chapter 22 Project management 5
6. Factors influencing project management
Company size
Software customers
Software size
Software type
Organizational culture
Software development processes
These factors mean that project managers in different
organizations may work in quite different ways.
04/12/2014 Chapter 22 Project management 6
7. Universal management activities
Project planning
Project managers are responsible for planning. estimating and
scheduling project development and assigning people to tasks.
Covered in Chapter 23.
Risk management
Project managers assess the risks that may affect a project,
monitor these risks and take action when problems arise.
People management
Project managers have to choose people for their team and
establish ways of working that leads to effective team
performance.
04/12/2014 Chapter 22 Project management 7
8. Management activities
Reporting
Project managers are usually responsible for reporting on the
progress of a project to customers and to the managers of the
company developing the software.
Proposal writing
The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work. The
proposal describes the objectives of the project and how it will be
carried out.
04/12/2014 Chapter 22 Project management 8
10. Risk management
Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
Software risk management is important because of the
inherent uncertainties in software development.
These uncertainties stem from loosely defined requirements,
requirements changes due to changes in customer needs,
difficulties in estimating the time and resources required for
software development, and differences in individual skills.
You have to anticipate risks, understand the impact of
these risks on the project, the product and the business,
and take steps to avoid these risks.
04/12/2014 Chapter 22 Project management 10
11. Risk classification
There are two dimensions of risk classification
The type of risk (technical, organizational, ..)
what is affected by the risk:
Project risks affect schedule or resources;
Product risks affect the quality or performance of the
software being developed;
Business risks affect the organisation developing or
procuring the software.
04/12/2014 Chapter 22 Project management 11
12. Examples of project, product, and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.
CASE tool
underperformance
Product CASE tools, which support the project, do not
perform as anticipated.
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
04/12/2014 Chapter 22 Project management 12
13. The risk management process
Risk identification
Identify project, product and business risks;
Risk analysis
Assess the likelihood and consequences of these risks;
Risk planning
Draw up plans to avoid or minimise the effects of the risk;
Risk monitoring
Monitor the risks throughout the project;
04/12/2014 Chapter 22 Project management 13
15. Risk identification
May be a team activities or based on the individual
project manager’s experience.
A checklist of common risks may be used to identify risks
in a project
Technology risks.
Organizational risks.
People risks.
Requirements risks.
Estimation risks.
04/12/2014 Chapter 22 Project management 15
16. Examples of different risk types
Risk type Possible risks
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Organizational The organization is restructured so that different management are responsible for
the project. (6)
Organizational financial problems force reductions in the project budget. (7)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Requirements Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Technology The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be reused
as planned. (2)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
04/12/2014 Chapter 22 Project management 16
17. Risk analysis
Assess probability and seriousness of each risk.
Probability may be very low, low, moderate, high or very
high.
Risk consequences might be catastrophic, serious,
tolerable or insignificant.
04/12/2014 Chapter 22 Project management 17
18. Risk types and examples
Risk Probability Effects
Organizational financial problems force reductions in the
project budget (7).
Low Catastrophic
It is impossible to recruit staff with the skills required for the
project (3).
High Catastrophic
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to be repaired
before these components are reused. (2).
Moderate Serious
Changes to requirements that require major design rework
are proposed (10).
Moderate Serious
The organization is restructured so that different
management are responsible for the project (6).
High Serious
The database used in the system cannot process as many
transactions per second as expected (1).
Moderate Serious
04/12/2014 Chapter 22 Project management 18
19. Risk types and examples
Risk Probability Effects
The time required to develop the software is
underestimated (12).
High Serious
Software tools cannot be integrated (9). High Tolerable
Customers fail to understand the impact of requirements
changes (11).
Moderate Tolerable
Required training for staff is not available (5). Moderate Tolerable
The rate of defect repair is underestimated (13). Moderate Tolerable
The size of the software is underestimated (14). High Tolerable
Code generated by code generation tools is inefficient (8). Moderate Insignificant
04/12/2014 Chapter 22 Project management 19
20. Risk planning
Consider each risk and develop a strategy to manage
that risk.
Avoidance strategies
The probability that the risk will arise is reduced;
Minimization strategies
The impact of the risk on the project or product will be reduced;
Contingency plans
If the risk arises, contingency plans are plans to deal with that
risk;
04/12/2014 Chapter 22 Project management 20
21. What-if questions
What if several engineers are ill at the same time?
What if an economic downturn leads to budget cuts of
20% for the project?
What if the performance of open-source software is
inadequate and the only expert on that open source
software leaves?
What if the company that supplies and maintains
software components goes out of business?
What if the customer fails to deliver the revised
requirements as predicted?
04/12/2014 Chapter 22 Project management 21
22. Strategies to help manage risk
Risk Strategy
Organizational financial
problems
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business and presenting
reasons why cuts to the project budget would not be cost-
effective.
Recruitment problems Alert customer to potential difficulties and the possibility of
delays; investigate buying-in components.
Staff illness Reorganize team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective components Replace potentially defective components with bought-in
components of known reliability.
Requirements changes Derive traceability information to assess requirements
change impact; maximize information hiding in the design.
04/12/2014 Chapter 22 Project management 22
23. Strategies to help manage risk
Risk Strategy
Organizational
restructuring
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Database
performance
Investigate the possibility of buying a higher-performance
database.
Underestimated
development time
Investigate buying-in components; investigate use of a
program generator.
04/12/2014 Chapter 22 Project management 23
24. Risk monitoring
Assess each identified risks regularly to decide whether
or not it is becoming less or more probable.
Also assess whether the effects of the risk have
changed.
Each key risk should be discussed at management
progress meetings.
04/12/2014 Chapter 22 Project management 24
25. Risk indicators
Risk type Potential indicators
Estimation Failure to meet agreed schedule; failure to clear reported defects.
Organizational Organizational gossip; lack of action by senior management.
People Poor staff morale; poor relationships amongst team members; high staff
turnover.
Requirements Many requirements change requests; customer complaints.
Technology Late delivery of hardware or support software; many reported
technology problems.
Tools Reluctance by team members to use tools; complaints about CASE
tools; demands for higher-powered workstations.
04/12/2014 Chapter 22 Project management 25
27. Managing people
People are an organisation’s most important assets.
The tasks of a manager are essentially people-oriented.
Unless there is some understanding of people,
management will be unsuccessful.
Poor people management is an important contributor to
project failure.
04/12/2014 Chapter 22 Project management 27
28. People management factors
Consistency
Team members should all be treated in a comparable way
without favourites or discrimination.
Respect
Different team members have different skills and these
differences should be respected.
Inclusion
Involve all team members and make sure that people’s views are
considered.
Honesty
You should always be honest about what is going well and what
is going badly in a project.
04/12/2014 Chapter 22 Project management 28
29. Motivating people
An important role of a manager is to motivate the people
working on a project.
Motivation means organizing the work and the working
environment to encourage people to work effectively.
If people are not motivated, they will not be interested in the work
they are doing. They will work slowly, be more likely to make
mistakes and will not contribute to the broader goals of the team
or the organization.
Motivation is a complex issue but it appears that their are
different types of motivation based on:
Basic needs (e.g. food, sleep, etc.);
Personal needs (e.g. respect, self-esteem);
Social needs (e.g. to be accepted as part of a group).
04/12/2014 Chapter 22 Project management 29
31. Need satisfaction
In software development groups, basic physiological and
safety needs are not an issue.
Social
Provide communal facilities;
Allow informal communications e.g. via social networking
Esteem
Recognition of achievements;
Appropriate rewards.
Self-realization
Training - people want to learn more;
Responsibility.
04/12/2014 Chapter 22 Project management 31
32. Case study: Individual motivation
04/12/2014 Chapter 22 Project management 32
Alice is a software project manager working in a company that develops alarm systems.
This company wishes to enter the growing market of assistive technology to help elderly and
disabled people live independently. Alice has been asked to lead a team of 6 developers
than can develop new products based around the company’s alarm technology.
Alice’s assistive technology project starts well. Good working relationships develop within
the team and creative new ideas are developed. The team decides to develop a peer-to-
peer messaging system using digital televisions linked to the alarm network for
communications. However, some months into the project, Alice notices that Dorothy, a
hardware design expert, starts coming into work late, the quality of her work deteriorates
and, increasingly, that she does not appear to be communicating with other members of the
team.
Alice talks about the problem informally with other team members to try to find out if
Dorothy’s personal circumstances have changed, and if this might be affecting her work.
They don’t know of anything, so Alice decides to talk with Dorothy to try to understand the
problem.
33. Case study: Individual motivation
04/12/2014 Chapter 22 Project management 33
After some initial denials that there is a problem, Dorothy admits that she has lost
interest in the job. She expected that she would be able to develop and use her
hardware interfacing skills. However, because of the product direction that has been
chosen, she has little opportunity for this. Basically, she is working as a C programmer
with other team members.
Although she admits that the work is challenging, she is concerned that she is not
developing her interfacing skills. She is worried that finding a job that involves
hardware interfacing will be difficult after this project. Because she does not want to
upset the team by revealing that she is thinking about the next project, she has
decided that it is best to minimize conversation with them.
34. Comments on case study
If you don’t sort out the problem of unacceptable work,
the other group members will become dissatisfied and
feel that they are doing an unfair share of the work.
Personal difficulties affect motivation because people
can’t concentrate on their work. They need time and
support to resolve these issues, although you have to
make clear that they still have a responsibility to their
employer.
Alice gives Dorothy more design autonomy and
organizes training courses in software engineering that
will give her more opportunities after her current project
has finished.
04/12/2014 Chapter 22 Project management 34
35. Personality types
The needs hierarchy is almost certainly an over-
simplification of motivation in practice.
Motivation should also take into account different
personality types:
Task-oriented people, who are motivated by the work they do. In
software engineering.
Interaction-oriented people, who are motivated by the presence
and actions of co-workers.
Self-oriented people, who are principally motivated by personal
success and recognition.
04/12/2014 Chapter 22 Project management 35
36. Personality types
Task-oriented.
The motivation for doing the work is the work itself;
Self-oriented.
The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel etc.;
Interaction-oriented
The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.
04/12/2014 Chapter 22 Project management 36
37. Motivation balance
Individual motivations are made up of elements
of each class.
The balance can change depending on personal
circumstances and external events.
However, people are not just motivated by personal
factors but also by being part of a group and culture.
People go to work because they are motivated by the
people that they work with.
04/12/2014 Chapter 22 Project management 37
39. Teamwork
Most software engineering is a group activity
The development schedule for most non-trivial software projects
is such that they cannot be completed by one person working
alone.
A good group is cohesive and has a team spirit. The
people involved are motivated by the success of the
group as well as by their own personal goals.
Group interaction is a key determinant of group
performance.
Flexibility in group composition is limited
Managers must do the best they can with available people.
04/12/2014 Chapter 22 Project management 39
40. Group cohesiveness
In a cohesive group, members consider the group to be
more important than any individual in it.
The advantages of a cohesive group are:
Group quality standards can be developed by the group
members.
Team members learn from each other and get to know each
other’s work; Inhibitions caused by ignorance are reduced.
Knowledge is shared. Continuity can be maintained if a group
member leaves.
Refactoring and continual improvement is encouraged. Group
members work collectively to deliver high quality results and fix
problems, irrespective of the individuals who originally created
the design or program.
04/12/2014 Chapter 22 Project management 40
41. Team spirit
04/12/2014 Chapter 22 Project management 41
Alice, an experienced project manager, understands the importance of creating a
cohesive group. As they are developing a new product, she takes the opportunity of
involving all group members in the product specification and design by getting them to
discuss possible technology with elderly members of their families. She also encourages
them to bring these family members to meet other members of the development group.
Alice also arranges monthly lunches for everyone in the group. These lunches are an
opportunity for all team members to meet informally, talk around issues of concern, and
get to know each other. At the lunch, Alice tells the group what she knows about
organizational news, policies, strategies, and so forth. Each team member then briefly
summarizes what they have been doing and the group discusses a general topic, such as
new product ideas from elderly relatives.
Every few months, Alice organizes an ‘away day’ for the group where the team spends
two days on ‘technology updating’. Each team member prepares an update on a relevant
technology and presents it to the group. This is an off-site meeting in a good hotel and
plenty of time is scheduled for discussion and social interaction.
42. The effectiveness of a team
The people in the group
You need a mix of people in a project group as software
development involves diverse activities such as negotiating with
clients, programming, testing and documentation.
The group organization
A group should be organized so that individuals can contribute to
the best of their abilities and tasks can be completed as
expected.
Technical and managerial communications
Good communications between group members, and between
the software engineering team and other project stakeholders, is
essential.
04/12/2014 Chapter 22 Project management 42
43. Selecting group members
A manager or team leader’s job is to create a cohesive
group and organize their group so that they can work
together effectively.
This involves creating a group with the right balance of
technical skills and personalities, and organizing that
group so that the members work together effectively.
04/12/2014 Chapter 22 Project management 43
44. Assembling a team
May not be possible to appoint the ideal people to work on
a project
Project budget may not allow for the use of highly-paid staff;
Staff with the appropriate experience may not be available;
An organisation may wish to develop employee skills on a
software project.
Managers have to work within these constraints especially
when there are shortages of trained staff.
04/12/2014 Chapter 22 Project management 44
45. Group composition
Group composed of members who share the
same motivation can be problematic
Task-oriented - everyone wants to do their own thing;
Self-oriented - everyone wants to be the boss;
Interaction-oriented - too much chatting, not enough work.
An effective group has a balance of all types.
This can be difficult to achieve software engineers are
often task-oriented.
Interaction-oriented people are very important as they
can detect and defuse tensions that arise.
04/12/2014 Chapter 22 Project management 45
46. Group composition
04/12/2014 Chapter 22 Project management 46
In creating a group for assistive technology development, Alice is aware of the
importance of selecting members with complementary personalities. When interviewing
potential group members, she tried to assess whether they were task-oriented, self-
oriented, or interaction-oriented. She felt that she was primarily a self-oriented type
because she considered the project to be a way of getting noticed by senior
management and possibly promoted. She therefore looked for one or perhaps two
interaction-oriented personalities, with task-oriented individuals to complete the team.
The final assessment that she arrived at was:
Alice—self-oriented
Brian—task-oriented
Bob—task-oriented
Carol—interaction-oriented
Dorothy—self-oriented
Ed—interaction-oriented
Fred—task-oriented
47. Group organization
The way that a group is organized affects the decisions
that are made by that group, the ways that information is
exchanged and the interactions between the
development group and external project stakeholders.
Key questions include:
• Should the project manager be the technical leader of the group?
• Who will be involved in making critical technical decisions, and how
will these be made?
• How will interactions with external stakeholders and senior company
management be handled?
• How can groups integrate people who are not co-located?
• How can knowledge be shared across the group?
04/12/2014 Chapter 22 Project management 47
48. Group organization
Small software engineering groups are usually organised
informally without a rigid structure.
For large projects, there may be a hierarchical structure
where different groups are responsible for different sub-
projects.
Agile development is always based around an informal
group on the principle that formal structure inhibits
information exchange
04/12/2014 Chapter 22 Project management 48
49. Informal groups
The group acts as a whole and comes to a consensus
on decisions affecting the system.
The group leader serves as the external interface of the
group but does not allocate specific work items.
Rather, work is discussed by the group as a whole and
tasks are allocated according to ability and experience.
This approach is successful for groups where all
members are experienced and competent.
04/12/2014 Chapter 22 Project management 49
50. Group communications
Good communications are essential for effective group
working.
Information must be exchanged on the status of work,
design decisions and changes to previous decisions.
Good communications also strengthens group cohesion
as it promotes understanding.
04/12/2014 Chapter 22 Project management 50
51. Group communications
Group size
The larger the group, the harder it is for people to communicate
with other group members.
Group structure
Communication is better in informally structured groups than in
hierarchically structured groups.
Group composition
Communication is better when there are different personality
types in a group and when groups are mixed rather than single
sex.
The physical work environment
Good workplace organisation can help encourage
communications.
04/12/2014 Chapter 22 Project management 51
52. Key points
Good project management is essential if software engineering
projects are to be developed on schedule and within budget.
Software management is distinct from other engineering
management. Software is intangible. Projects may be novel or
innovative with no body of experience to guide their management.
Software processes are not as mature as traditional engineering
processes.
Risk management involves identifying and assessing project risks to
establish the probability that they will occur and the consequences
for the project if that risk does arise. You should make plans to
avoid, manage or deal with likely risks if or when they arise.
04/12/2014 Chapter 22 Project management 52
53. Key points
People management involves choosing the right people to work on a
project and organizing the team and its working environment.
People are motivated by interaction with other people, the
recognition of management and their peers, and by being given
opportunities for personal development.
Software development groups should be fairly small and cohesive.
The key factors that influence the effectiveness of a group are the
people in that group, the way that it is organized and the
communication between group members.
Communications within a group are influenced by factors such as
the status of group members, the size of the group, the gender
composition of the group, personalities and available communication
channels.
04/12/2014 Chapter 22 Project management 53