Handout10.docx

**Week\#11 - Project Management** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - - - -...

**Week\#11 - Project Management** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - - - - | +-----------------------------------------------------------------------+ **Software project management** Interested in the steps required to ensure that software is delivered on schedule, according to plan, and in accordance with the requirements of the businesses generating and purchasing the software. Because software development is always subject to time and financial restraints imposed by the company creating the system, project management is necessary. **Success criteria in project management** - Provide the customer with the program at the scheduled time. - Maintain total costs within the budget. - Provide customers with software that lives up to their expectations. - Retain a cohesive and effective development team. **Software management distinctions** - **The software is intangible**. Software is invisible and touchless. Managers of software projects cannot gauge progress by merely looking at the artefact that is being built. - **Most software projects are \'one-off\' projects.** Most of software projects typically differ from earlier initiatives in some respects. Even very experienced managers could find it challenging to foresee issues. - **Software processes vary and are unique to each environment.** We are still unable to accurately forecast when a specific software procedure would most likely cause issues during development. **Factors influencing project management** - Software size - Software development processes - Software customers - Company size - Software type - Organizational culture Due to these characteristics, project managers in various system developments may operate in quite diverse ways. **Universal management activities** - **Project planning**: Planning is the responsibility of project managers. Scheduling and estimating project development, as well as task assignment. - **Risk management**: A project\'s potential risks are assessed by project managers, who also monitor them and act when problems arise. - **People management**: To ensure effective team performance, project managers must choose team members and establish working procedures. **Management activities** - **Reporting**: Project managers are typically responsible for providing regular updates on a project\'s status to clients and the managers of the software development company. - **Proposal writing**: A proposal may need to be written as the initial step in a software project in order to secure a contract to complete a task. The project\'s goals and the plan for execution are laid out in the proposal. **Risk management** Identifying risks and coming up with solutions to lessen their influence on a project are the objectives of risk management. Software risk management is essential due to the inherent threats in software development. Uncertainties are brought on by unclear requirements, changes to requirements brought on by evolving client expectations, difficulties estimating the time and resources required for software development, and individual skill gaps. In order to limit or eliminate risks, you must be ready for them, understand how they may impact your project, your product, and your business, and take appropriate steps. - **Risk classification** - The classification of risk has two aspects. - The kind of risk (technical, organizational, etc.) - What is impacted by the risk? - Product risks affect the program\'s usability or quality as it is being developed. - Resources or schedule are impacted by project risks. - Business risks affect the organization that develops or purchases the software. Examples of product, project, and business risks -------------------------------------------------- ------------- ----------------- **Risk** **Affects** **Description** - **The risk management process** - Risk identification: List potential risks to a project, a product, or a business. - Risk analysis: Evaluate the probability and effects of various risks. - Risk planning: Create strategies to reduce or eliminate the risk\'s impacts. - Risk monitoring: Keep an eye on the hazards as the project progresses. Figure 11.1. The procedure for managing risks - **Risk identification** - - - - - +-----------------------------------+-----------------------------------+ | Examples of different risk types | | +===================================+===================================+ | **Risk type** | **Possible risks** | +-----------------------------------+-----------------------------------+ | Technology | The system\'s database is unable | | | to handle the anticipated number | | | of transactions per second. (1) | | | | | | Reusable software components have | | | flaws that prevent them from | | | being used as intended. (2) | +-----------------------------------+-----------------------------------+ | People | Staff with the necessary skills | | | cannot be hired. (3) | | | | | | Critical personnel are sick and | | | unavailable at crucial periods. | | | (4) | | | | | | The necessary staff training is | | | not offered. (5) | +-----------------------------------+-----------------------------------+ | Organizational | The organization has been | | | reorganized so that various | | | management is in charge of the | | | project. (6) | | | | | | Organizational financial issues | | | necessitate budget cuts for the | | | project. (7) | +-----------------------------------+-----------------------------------+ | Tools | Software code creation tools | | | provide ineffective code. (8) | | | | | | Software tools cannot be merged | | | to operate as a single unit. (9) | +-----------------------------------+-----------------------------------+ | Requirements | Requirements adjustments that | | | necessitate significant design | | | revision are suggested. (10) | | | | | | Customers lack the understanding | | | of how shifting needs might | | | affect them. (11) | +-----------------------------------+-----------------------------------+ | Estimation | The program\'s development takes | | | longer than predicted. (12) | | | | | | Underestimation of the rate of | | | fault correction. (13) | | | | | | The software\'s size is | | | overestimated. (14) | +-----------------------------------+-----------------------------------+ - **Risk analysis** - Determine the likelihood and importance of each risk. - The probability could be very low, low, moderate, high, or very high. - The effects of a risk could be disastrous, severe, bearable, or inconsequential. Risk types and examples ---------------------------------------------------------------------------------------------------- ----------------- --------------- **Risk** **Probability** **Effects** The system\'s database cannot handle as many transactions per second as anticipated (1). Moderate Serious Reusable software components must first have any flaws fixed before being used again. (2). Moderate Serious Staff with the necessary abilities for the project cannot be hired (3). High Catastrophic During crucial phases of the project, key personnel are ill (4). Moderate Serious Staff training that is necessary is not offered (5). Moderate Tolerable The organization has been reorganized so that several management are in charge of the project (6). High Serious Reductions in the project budget are required by organizational financial issues (7). Low Catastrophic Code produced by tools for code generation is ineffective (8). Moderate Insignificant There is no way for integrating software tools (9). High Tolerable Requirements changes that necessitate significant design revision are suggested (10). Moderate Serious The effects of changing requirements are not understood by customers (11). Moderate Tolerable It takes longer than expected to develop the software (12). High Serious Defect repair rates are overestimated (13). Moderate Tolerable Underestimating the software\'s size (14). High Tolerable - **Risk planning** - - - - **What-if questions** - What happens if the firm that provides and maintains software components fails? - What if the project\'s budget is reduced by 20% due to a recession? - What happens if multiple engineers fall unwell at the same time? - What if the single expert on the open-source software is no longer there and the performance of the software is subpar? - What happens if the customer doesn\'t deliver the updated needs on time? Techniques for reducing risk ----------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Risk** **Technique** Staff illness Rearrange the team so that tasks overlap more and employees are more aware of one another\'s responsibilities. Organizational restructuring Create a briefing report for top management that demonstrates how the project is significantly advancing the company\'s objectives. Organizational financial problems Describe the project\'s major contribution to the company\'s goals and the reasons why budget cuts for the project would not be cost-effective in a briefing report for top management. Requirements changes Maximize information hiding in the design and derive traceability information to evaluate the impact of requirements changes. Underestimated development time Look into purchasing components and using a program generator. Defective components Replace possibly damaged components with new ones that have been purchased and are known to be reliable. Recruitment problems Inform the customer of probable issues and potential delays; look into purchasing components. Database performance Look at the option of purchasing a more performant database. - **Risk monitoring** - Regularly assess each risk indicated to determine whether it is growing more or less likely. - Examine whether the risk\'s impacts have altered as well. - Meetings to review the status of management should cover each significant risk. Risk indicators ----------------- ------------------------------------------------------------------------------------------------------------------------- **Risk type** **Relevant indicators** Requirements Numerous requests to modify criteria and customer concerns. Organizational Disinformation within the company; inaction on the part of upper management. Technology Several complaints about technical issues; late hardware or support software deliveries. Estimation Failure to correct stated problems; failure to stick to the agreed-upon schedule. Tools Team members\' reluctance to use tools, complaints regarding CASE tools, and requests for workstations with more power. People High worker turnover, poor team dynamics, and low employee morale. **Managing people** The most valuable resource in any organization is its people. Most of a manager\'s responsibilities are people-related. If management does not have some understanding of people, it will fail. Poor people management is mostly to blame for project failure. - **Factors affecting people management** - **Honesty**: You should always be honest about both the good and the poor aspects of a project. - **Consistency**: Team members must be treated equally, without favouritism or prejudice. - **Inclusion**: Include every team member and make sure that everyone\'s opinions are taken into account. - **Respect**: Team members differ in their skill sets, and it is important to acknowledge and value these distinctions. - **Encouraging and motivating people** - Personal needs (e.g. self-esteem , respect) - Basic needs (e.g. sleep, food, etc.) - Social needs (e.g. to be welcomed as a member of a group)  Figure 11.2. Human need classifications - **Need satisfaction** - **Self-realization**: Responsibility; education; people want to learn more. - - - **Personality types** - **Interaction-oriented people**, who are inspired by their co-workers' presence and behaviour. The presence and behaviour of co-workers serve as the primary motivation. People choose to work because they enjoy it. - **Task-oriented people**, people are inspired by their work. The work itself serves as the incentive in software engineering. - **Self-oriented people**, they are driven only by their own achievement and recognition. The employment serves as a vehicle for achieving personal objectives, such as becoming wealthy, learning to play tennis, traveling, etc. - **Motivational balance** - Each class\'s components are present in each person\'s motivations. - Depending on internal and external factors, the balance may change. - People are nevertheless motivated by social and cultural influences in addition to personal ones. - People go to work because the people they work with inspire them. **Teamwork management** Most software engineering is carried out in teams. Most non-trivial software projects cannot be completed by a single individual working alone because of their development timeframes. A strong team is cohesive and has a sense of unity. The success of the group and the individuals\' own goals are what motivate them. Group performance is significantly influenced by group interaction. There is little room for compositional flexibility. Managers must make the most use of the personnel at their disposal. - **Group cohesiveness** - Group members may create collective quality criteria. - Knowledge-based inhibitions are reduced as a result of team members learning from one another and becoming familiar with one another\'s work. - Information is shared. If one of the group members leaves, continuity can still be kept. - Refactoring and on-going development are welcomed. Regardless matter who originated the concept or software, members of the group work together to create excellent results and find solutions to problems. - **The effectiveness of a team** - **The team members:** You need a variety of team members because software development requires a variety of tasks, including customer negotiations, programming, testing, and documentation. - **The structure of the group:** A group should be structured to allow for each member to participate to the best of their skills and the efficient completion of duties. - **Technical and management communications**: It\'s critical for the software engineering team to effectively communicate with all project stakeholders. - **Choosing group participants** - **Forming a team** - **Makeup of the group** - **Group organization** - Who will participate in important technical decision-making, and how will these decisions be made? - Should the project manager be the team\'s technical leader? - How can groups include members who don\'t share a space? - How will relationships with top firm management and external stakeholders be handled? - How could information be distributed across the group? - **Informal groups** - **Group communications** - The setting of the workplace: Communications can be aided by effective workplace organization. - Group size: People find it more difficult to converse with one another in huge groups. - Group composition: Different personality types and mixed-sex groups do better in terms of communication than single-sex ones. - Group structure: Informally structured groups communicate better than hierarchically structured ones. **Summary** - Effective project management is essential if software engineering projects are to be completed on time and on budget. - Engineering management is different from software management. Intangibles include software. The administration of projects that lack a body of experience may be unique or inventive. The maturity of software processes is lower than that of conventional engineering procedures. - Risk management entails identifying and evaluating project risks to determine their likelihood of happening and the effects on the project should they. You must prepare for potential risks so that you can avoid, control, or handle them if and when they occur. - Choosing the best team members and setting up the team\'s workspace are both parts of people management. - Interaction with others, receiving praise from management and peers, and having opportunities for personal growth are all motivating factors for people. - Software development teams should be cohesive and comparatively small. The individuals that make up a group, the way that group is structured, and the level of communication among group members are the main determinants of that group\'s efficacy. - There are several factors that influence communication inside a group, including the status of group members, the size of the group, and the gender mix of the group, personalities, and available communication technologies.