Software Project Management (SPM) Week 1 Notes PDF

CPS714: Software Project Management Lesson1:Introduction Course Summary Instructor Lectures Prof. Manar Alalfi Tue, 9:00-12:00, [email protected] Office Hours Friday 11:00 AM-12:00 PM, or by appointment Course Summary Goal of the Course Course Project SPM Stories Concepts, theory, and An opportunity to put Includes experiences practice of software what you learn into from industry and project management practice. You will form reviews of real small software companies applications of SPM and design and build a small high quality software product applying SPM practices Motivations (1/2) Many courses in computer science and electronic engineering focus on the technical aspects and on the notations to develop good software (e.g., how to do testing; how to write requirements; how to model systems; UML; Java) However, in order to build good software, a well defined and managed process, which organizes the activities in an efficient and controlled way spm - ©2014 adolfo villafiorita - introduction to software project management 4 Major Topics Introduction to Project Management Project Management Process Project Integration Management Project Scope Management Project Scheduling and Tracking Project Procurement Management Software Cost Estimation Project Quality Management References Compulsory textbook: none. Reference textbooks include Kathy Schwalbe (2019). Information Technology Project Management, 9th Edition. Cengage. Adolfo Villafiorita (2016). Introduction to Software Project Management. Boca Raton, FL: CRC Press/Auerbach Publications. Robert K. Wysocki (2017). Effective Project Management: Traditional, Agile, Extreme, 7th edition. Wiley. David J. Anderson (2004). Agile Management for Software Engineering. New Saddle River, NJ: Pearson Education Inc. Erik W. Larson and Clifford F. Gray (2017). Project Management: The Managerial Process. New York, NY: McGraw-Hill Higher Education. Course and Project Theme Five assignments-based group project: Students will be assigned to groups of up to 5 members. Students will need to have access to project management software such as Microsoft Project or its functional equivalents that can be found for free on the Internet. Late submission will be penalized by one (1) percent for each day of delay. Submissions that are more than three days late will receive zero marks Project Management Software* There are hundreds of different products to assist in performing project management Three main categories of tools: o Low-end tools: Handle single or smaller projects well, cost under $200 per user o Midrange tools: Handle multiple projects and users, cost $200-$1,000 per user, Microsoft Project is still the most popular o High-end tools: Also called enterprise project management software, often licensed on a per-user basis Several free or open-source tools are also available: Jira, Clickup, Zoho Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Project Management Tools and Techniques Project management tools and techniques assist project managers and their teams in various aspects of project management Some specific ones include Project charter, scope statement, and WBS (scope) Gantt charts, network diagrams, critical path analysis, critical chain scheduling (time) Cost estimates and earned value management (cost) Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Marking Scheme 5 - Assignment-based project with final 30% Presentation and peer-evaluation 1-2 Term Tests 60% Quizzes/Assignments 10% Who I am? ~15 years teaching, professional and research experience in Software Engineering: 7 years at TMU! 3 years at Alfaisal University! 9 As an Adjunct Assistant Professor in Software Engineering ( Queen’s U). One year Adjunct Assistant professor SE (KAUST), 3 years Lecturer (HU). Research Interest Software Security Analysis: Internet of Things Blockchain Mobile Applications Web applications Machine learning for cybersecurity Software Design Recovery and Evolution: Migrating Web applications to SOA Migrating SQL-based to NoSQL-based web applications Detection of features Interactions in scripting languages Model Driven Software Engineering: Model patterns Engineering Model variability Identification and representations Research Interest Software Security for IoT and Automotive Infotainment Systems: 1. Abdul Moiz*, Manar H. Alalfi “An Approach for the identification of information leakage in Automotive Infotainment systems”. 20th IEEE International SCAM 2020. 2. Florian Schmeidl*, Bara Nazzal*, Manar H. Alalfi “Security Analysis for SmartThings IoT Applications”, 6th IEEE/ACM ICSE2019 (MobileSoft). 3. Atheer Abu Zaid*, Manar H. Alalfi, Ali Miri, “Automated Identification of Over-Privileged SmartThings Apps”, (ICSME2019). 4. Hajra Irshad*, Manar H. Alalfi “Predicting Vulnerabilities in IoT Applications”, SANER2019. 5. S. Parveen*, Manar H. Alalfi “ A Mutation Framework for Evaluating Security Analysis tools in IoT Applications”, SANER2020. Software Security for Blockchain: 1. Mehmet Demir*, Manar H. Alalfi, Alexander Ferworn, Ozgur Turetken, “Security Smells in Smart Contracts”, QRS2019. 2. N. Samreen*, Manar H. Alalfi “Reentrancy Vulnerability Identification in Ethereum Smart Contracts.” SANER 2020 3. N. Samreen*, Manar H. Alalfi “A Survey of Security Vulnerabilities in Ethereum Smart Contracts”. CASCON’2020. Software Evolution 1. Rahma Al Mahruqi*, M. H. Alalfi and Thomas Dean "A semi-automated Framework for Migrating Web applications from SQL to NoSQL database", CASCON’19. 2. Omar Al Harthi*, M. H. Alalfi, Thomas Dean "Detection of Feature Interaction in Dynamic Scripting Languages", CASCON’19. MDE for Automotive Systems 1. Chen J.*, Alalfi M.H., Dean T.R., Ramesh S. (2018) Modeling AUTOSAR Implementations in Simulink. Modelling Foundations and Applications. ECMFA 2018. Lecture Notes in Computer Science, Springer vol 10890, pp.279-292. 2. M. H. Alalfi, E.J. Rapos*, A. Stevenson*, M. Stephan*, T.R. Dean and J.R. Cordy, Variability Identification and Representation for Automotive Simulink Models”, book chapter, Springer, Automotive System and Software Engineering - State of the Art and Future Trends 2019. Why Software Project Management? Motivations (2/2) If you want to deliver on time and within budget a product which has the quality properties agreed upon (be it a software or any other product), you need: – A process to define a schedule, a budget, and agree on the (quality) characteristics of a product – A list of techniques to define, agree, plan, execute, and monitor: goals, quality, time, and costs spm - ©2014 adolfo villafiorita - introduction to software project management 17 Skills and some goals of the course Managing a (software development) project, thus, requires specific competences, skills, and techniques Some of the questions you will be able to answer at the end of this course include: – How do I estimate how long it will take to complete a task? – How much am I going to charge for a project? – How do I keep the team motivated and ensure projects are fulfilling and an occasion to learn, grow, and advance in one’s career? – How do I deal with project risks? – How do I assess whether the project is on time, on budget, on schedule? – How do I control the quality of the final output? spm - ©2014 adolfo villafiorita - introduction to software project management 18 Software Project Management The Project Management techniques are intrinsically multidisciplinary … … what you will learn in this course is applicable to virtually any other (engineering) domain. There are however certain characteristics that make the management of software projects particularly interesting. spm - ©2014 adolfo villafiorita - introduction to software project management 19 Software Project Management Software project management is interesting and challenging because: – The product is intangible – The product is uniquely flexible (e.g. different sizes; different constraints) – Many software projects are 'one-off' – The development process is uniquely flexible – Size and complexity are increasing exponentially – Human lives might depend on software running as expected (consider the control system of an airplane)- safety critical systems spm - ©2014 adolfo villafiorita - introduction to software project management 20 Complexity The entire Saturn V stack, that is, all three stages of the booster plus the command module and the lunar module, had less computing capacity combined than today’s typical cell phone. Source: Apollo by Charles Murray and Catherine Bly Cox spm - ©2014 adolfo villafiorita - introduction to software project management 21 Software Development Projects and Stakeholders The name of the game, the players, and (some of) the rules Goals of this Unit Understanding what is a project, what is the life cycle of a project and how it differs from other types of works Understanding the players and the relationships among them Understanding the influences organizations exert on project and project executions spm - ©2014 adolfo villafiorita - introduction to software project management 2 What is a project The name of the game A project is a temporary endeavor undertaken to create a unique product, service, or result (definition from the PMBOK) Characteristics of a Project Temporary – Definitive begin and end (either because the goals are met or the project is closed - goals cannot or will not be met) – Projects’ results are not necessarily temporary (see project and product lifecycle) Unique products, service, or result – A product which is quantifiable (e.g. a component, …) – A capability to perform a service, such a business function – A result, such as knowledge (collected in documents, presentation, …) Progressive elaboration – Development by steps and in increments (necessary to keep a project under scope) Resource constrained (like everything else in life) spm - ©2014 adolfo villafiorita - introduction to software project management 5 Progressive Elaboration Initiate Plan Execute Close Monitor Cumulative Work Time spm - ©2014 adolfo villafiorita - introduction to software project management 6 Project Management Context Subprojects – Projects may be divided in subprojects (although the sub- projects may be referred to as “projects” and managed as such) Project and Program Management – Set of related projects managed in a coordinated way in order to achieve some sort of benefit Portfolios and Portfolio Management – Collection of unrelated projects or programs and other work grouped together to facilitate management and meet strategic objectives spm - ©2014 adolfo villafiorita - introduction to software project management 7 Project Management Context A program is a collection of related projects that share a common goal or purpose. Program 1 Program 2 Project C Project E Project A Project D Project B Projects and Operational Work Work can be categorized either as project or operational Common characteristics – Performed by people – Limited resources – Planned, executed, and controlled Differences – Project: obtain goals and terminate – Operational work: sustain the business spm - ©2014 adolfo villafiorita - introduction to software project management 8 Examples (and counterexamples) Cooking dinner Building a car Designing a car Writing a paper Developing a software system Maintaining a software system Managing personnel spm - ©2014 adolfo villafiorita - introduction to software project management 9 Software Development Projects Some Examples of Software Development Projects and Operational Work Type of “Software” Development Projects In your life as a project manager you might be involved in different types of “software” development projects, among which: – Application Development – Process and Systems Re-Engineering – System Integration – Consulting Services – Installation and Training spm - ©2014 adolfo villafiorita - introduction to software project management 11 Application Development Goal: developing an application (desktop, web, mobile, embedded) The most fun :-) Types of application development: – One-oﬀ s: systems specifically created for a client – Oﬀ -the-shelf: to fill the need of a large set of users – Customized oﬀ -the-shelf: standardized systems which require a significant amount of customization to be used in an organization. Example: Enterprise Resource Planning (ERP) systems spm - ©2014 adolfo villafiorita - introduction to software project management 12 Process and Systems Re-Engineering Goal: change the way in which the operational work of an organization is carried out to achieve some strategic goal (e.g., improve quality, become more efficient) Typically large projects which involve an accurate analysis of the existing situation (“as is”) w.r.t. procedures, systems, infrastructure Often the support the introduction of an ERP system and require system and data integration activities spm - ©2014 adolfo villafiorita - introduction to software project management 13 System Integration Services Goal: automating the information flow among the systems of an organization Types of integration: – Horizontal: integration of systems performing similar operations – Vertical: integration of systems automating different steps of a procedure spm - ©2014 adolfo villafiorita - introduction to software project management 14 Other types of Projects Consulting Services – Typically asked to gain a know-how outsize a company’s core competence Installation and Training Services – Services related to the installation or training on specific software systems – Remark: also a revenue model in open source development spm - ©2014 adolfo villafiorita - introduction to software project management 15 Projects and their Environment The players (and you) A project stakeholder is any individual or an organization that is actively involved in a project, or whose interest might be affected (positively or negatively) as a result of project execution or completion. (PMBOK) spm - ©2014 adolfo villafiorita - introduction to software project management 17 The Players Some characteristics: – They may have different influence and varying level of responsibility during the project – They may play different roles – They may have positive or negative influence on the project – They may be difficult to identify – Their lack of intervention may negatively influence the project (need for identification and involvement) Remark: the project manager and the project team are project stakeholders, although the term is often used to refer to the “other” stakeholders spm - ©2014 adolfo villafiorita - introduction to software project management 18 Types of Stakeholders The project manager The project team The project sponsor The performing organizations The partners The client The “rest”: anyone who might be affected by the project outputs spm - ©2014 adolfo villafiorita - introduction to software project management 19 Key Stakeholders Internal: – Project team members: the group performing the work – Project management team: the members of the team directly involved in project management In between: – Customer/User: person or organization that will use the results of a project. There may be multiple layers of users – Sponsor: person or group providing the financial resources – Performing Organization: the organization mostly involved in the project External: – Influencers: people or groups not directly related to the project who could influence the course of a project spm - ©2014 adolfo villafiorita - introduction to software project management 20 The Project Manager (you) Project Manager – Person responsible of managing the project and stakeholders’ expectations Some skills – Communication and negotiation skills – A little predisposition to risk – Goal orientation – Leadership – A bit of thinking outside the schemes – Solid know-how – Professional correctness – A lot of common sense – A bit of style spm - ©2014 adolfo villafiorita - introduction to software project management 22 Organizing the Development of Software Projects Software Project Management Software project management is the integration of management techniques to software development. The need for such integration has its root in the sixties, in the days of the “software crisis”, when practitioners recognized the increasing complexity of delivering software products meeting the specifications spm 24 Software Development Framework A general software project management framework is meant to: – Form a shared vision about the goals to be achieved, the characteristics of the project outputs, and the characteristics of the development process – Structure the work as a progressive refinement, from specification to goals – Reduce the impact of uncertainties and unknowns – Highlight any deviation from the plan (goals, costs, quality) – Ensure the coherency and quality of the project artifacts over time and in spite of unknowns and (request for) changes – Motivate your team spm 26 Some Concerns Feasibility Assessment Goals (Scope) Management Time Management Cost Management Change Control and Configuration Management Quality Management Risk Management Human Resource Management spm 27 Initiate Plan Execute & Close Monitor Assess Formalize Collect Feasibility Goals Outputs Close Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Project and Product Life Cycles It is good practice to divide projects into several phases Because projects operate as part of a system and involve uncertainty The same can be said for developing products Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Project Life Cycle (1 of 2) A project life cycle is a collection of project phases that defines what work will be performed in each phase what deliverables will be produced and when who is involved in each phase, and how management will control and approve work produced in each phase A deliverable is a product or service produced or provided as part of a project Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Project Life Cycle (2 of 2) In early phases of a project life cycle resource needs are usually lowest the level of uncertainty (risk) is highest project stakeholders have the greatest opportunity to influence the project In middle phases of a project life cycle the certainty of completing a project improves more resources are needed The final phase of a project life cycle focuses on ensuring that project requirements were met the sponsor approves completion of the project Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Product Life Cycles (1 of 3) Products also have life cycles The Systems Development Life Cycle (SDLC) is a framework for describing the phases of developing information systems Systems development projects can follow Predictive life cycle Iterative life cycle Incremental life cycle Adaptive life cycle Hybrid life cycle Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Product Life Cycles (2 of 3) Predictive Life Cycle Models Waterfall model: has well-defined, linear stages of systems development and support Spiral model: shows that software is developed using an iterative or spiral approach rather than a linear approach Prototyping model: used for developing prototypes to clarify user requirements Rapid Application Development (RAD) model: used to produce systems quickly without sacrificing quality Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Product Life Cycles (3 of 3) Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. Scrum Information Technology Project Management, Ninth Edition. © 2019 Cengage. May not be copied, scanned, or duplicated, in whole or in part, except for use as permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use. (Traditional) Software Development Processes Goals of the Unit A gentle and high-level introduction to software development activities Understanding what are the building blocks for producing software Remarks: – This is no substitute for a software engineering course – The activities need to be integrated in a coherent process, to make sense – Software development projects range from the very small to the very large... not all activities equally useful or relevant in any context spm - ©2014 adolfo villafiorita - introduction to software project management 2 Initiate Plan Execute & Close Monitor Assess Formalize Collect Close Feasibility Goals Outputs Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Overview Software development is a progressive refinement which moves from concept to operations through the following phases: – Requirements and User Experience Design – Design – Implementation – Verification and Validation – Deployment – Operations and Maintenance As we move along these phases, we make and commit to specific choices; the cost of changes increases accordingly Different processes put different emphasis on each activity or define the order in which these activities can be performed spm - ©2014 adolfo villafiorita - introduction to software project management 4 Requirements Management Requirements Goal: – Forming a shared view about the characteristics of the system to build Output: – List of requirements, presented as: * a text document * a list of user stories * a set of diagrams (e.g., use case diagrams) and corresponding textual descriptions spm - ©2014 adolfo villafiorita - introduction to software project management 6 List of Requirements Format: – Free or structured text describing the functions and other properties of a system Advantages – Simple to draft and distribute – The format can be used to keep track of changes (versioning) Disadvantages – No focus on user interaction: it can be difficult to understand for a customer – Ambiguities and incoherencies; interactions among requirements spm - ©2014 adolfo villafiorita - introduction to software project management 7 Use Case Diagrams Format: – Diagrams describing the interaction between users and the system – Textual description of the interaction as a sequence of steps Advantages – Intuitive, simpler to understand for a customer – It focuses on what the system does (user functions) Disadvantages – Difficult to represent and keep track of non-functional requirements – Managing diagrams requires a bit more work than working with text only spm - ©2014 adolfo villafiorita - introduction to software project management 8 User Stories Format: – Structured textual descriptions of user functions: As a [user] I want to do [this] because [of that] Advantages – Intuitive, compact, and simple to understand for a customer – It focuses on what the system does (user functions) Disadvantages – Difficult to represent and keep track of non-functional requirements – It is a partial specification (many details need to be worked out during the implementation) - used by Agile methodologies spm - ©2014 adolfo villafiorita - introduction to software project management 10 Requirements Engineering Goal: – Define and maintain requirements over time Activities: – Requirements elicitation (workshops, brainstormings, focus groups, …) – Requirements structuring – User experience design – Requirements validation spm - ©2014 adolfo villafiorita - introduction to software project management 11 Requirements Structuring Goal: – Improving maintenance of requirements over time Tools: – Isolated and made identifiable (reason and manipulate each requirement more easily) – Organized and classified (e.g., FURPS) – Annotated (priority, importance, traceability, …) spm - ©2014 adolfo villafiorita - introduction to software project management 12 User Experience Design Goal: – Providing a coherent and satisfying experience on the different artifacts that constitute a software system, including its design, interface, interaction, and manuals Tools: – User-centered analysis: understanding how users will interact with the system (focus groups, experiments) – User-centered design: specifying how users will actually interact with the system (mock-ups) spm - ©2014 adolfo villafiorita - introduction to software project management 13 Requirements Validation Find (and address): – Inconsistencies * scenario 1: R1. A; …; Rn: not A * scenario 2: R1. forall x. A(x); …; Rn: not A(c) – Incompleteness * the behavior is not specified for certain cases and situations (often non-nominal situations) – Duplicates * the same requirements is described twice (possibly in different ways) spm - ©2014 adolfo villafiorita - introduction to software project management 14 Business Process Modeling and Re-engineering Organizations and Software Software has to be designed to fit an organization’s operational structure However: software can also change the way in which an organization work Business process modeling models the way in which an organization works Business process re-engineering plans the way in which an organization works, to make its operations more efficient (“as is” and “to be”) spm - ©2014 adolfo villafiorita - introduction to software project management 16 Business Process Modeling Articulated and complex, it is sometimes planned and organized as an independent project Conducted with interviews, document analysis, shadowing Information to collect: – Organizational structure: chain of responsibility and accountability – Business processes – Existing IT infrastructure: hardware, systems, databases – Business entities: data produced and processed by the organization spm - ©2014 adolfo villafiorita - introduction to software project management 17 System Design System Design Goal: – Defining the structure of the software to build (= system architecture) Outputs: – components which constitute the system – functions each component implements – how the components are interconnected The activity is relevant also for managerial reasons: the system architecture provides a “natural” decomposition of work spm - ©2014 adolfo villafiorita - introduction to software project management 19 Architectural Patterns C2 C1 C2 C3 C2 C2 C1 C3 C2 A Pipeline Architecture A Layered Architecture V updates M response request Client 1 C modifies request Client 2 Server database response V1 updates M V2 Client3 response request A Data-Centric applicaton with two MVCs A client-server Architecture spm - ©2014 adolfo villafiorita - introduction to software project management 20 Architectural Patterns Pipe and filter – Composition of data processing units – Focus: I/O specification Layered/Hierarchical – Hierarchy of components – Focus: control and information flow; block responsibilities Data-Centric – MVC: data, presentation, and logic – Focus: data model, operations – Many web applications and many desktop applications use the data-centric architectural style Client-server – Server (main functions) and clients (requesting services) – Focus: communication protocolo/service specifications spm - ©2014 adolfo villafiorita - introduction to software project management 21 Implementation Implementation Goal: – Writing the code! Some of the PM-relevant activities during implementation: – Collection of productivity and size metrics – Collection of quality metrics – Use of coding and documentation standards – Code management practices (versioning; code releasing standards) spm - ©2014 adolfo villafiorita - introduction to software project management 23 Verification and Validation Verification and Validation Validation = are we building the right system? Verification = did we build the system right? Collectively known with the acronym V&V Part of quality management The main (but not the only) way of performing V&V for software systems is testing spm - ©2014 adolfo villafiorita - introduction to software project management 25 Types of Testing Unit testing – Scope: a piece of code, such as a class Integration testing – Scope: the interaction between two components – Mars Climate Orbiter bug: two components used different units (metric and imperial); ~400M USD loss. System testing – Scope: the system behaves as expected and implements correctly all the requirements – Test cases Usability testing – Scope: verifying whether the user experience and interaction is intuitive, effective, and satisfying – Used to reduce the probability of human errors (safety-critical systems). spm - ©2014 adolfo villafiorita - introduction to software project management 26 The System Testing Process Fixing Requirements System [errors] Test Plan Test Test Plan Definition Execution [no errors] Test Cases Test Plan Test Report spm - ©2014 adolfo villafiorita - introduction to software project management 27 Deployment Deployment Goal – Installing the new system and making it operational Some concerns: – Ensuring continuity of business operations – Migrating data – Transitioning to operations and maintenance Factors to consider: – The human factor: is the people ready to use the system? – The data factor: is all the data which is needed for the system to run available to the new software? – The hardware factor: are all interfaces ready and functional? spm - ©2014 adolfo villafiorita - introduction to software project management 29 Approaches Cut-over: the new system replaces the old one Parallel Approach: the old and the new system operate simultaneously for a period Piloting: the new system is installed for a limited number of users or for a specific business unit Phased Approach: functions are rolled out incrementally spm - ©2014 adolfo villafiorita - introduction to software project management 30 Managing Software Evolution Project Development Team Project Testing Team Employees Development Testing Environment Production Environment Environment System Fake Data System Fake Data System Data System ready System, Project, and for testing Organization ready for production spm - ©2014 adolfo villafiorita - introduction to software project management 31 Operations and Maintenance Operations and Maintenance Goal – Ensuring the system runs smoothly Activities: – Providing Technical Support – Monitoring system performance – Collecting and managing tickets (clarifications, bugs, requests for improvement) – Trigger maintenance activities [ solution is not [a user reports a bug ] satisfactory ] Unconfirmed Confirmed In Progress Resolved Closed [ bug is not present, e.g. reported by mistake ] spm - ©2014 adolfo villafiorita - introduction to software project management 33 Types of Maintenance Corrective, if relative to fixing an issue discovered after the release of the system Preventive, if relative to fixing an issue discovered, but not occurred (or, at least, signaled by users) Adaptive, if relative to adapt a system to changed external conditions Perfective, if relative to improve some characteristics of a system, like, for instance, performances spm - ©2014 adolfo villafiorita - introduction to software project management 34 (Traditional) Software Development Activities Goals of the Unit A gentle and high-level introduction to software development activities Understanding what are the building blocks for producing software Remarks: – This is no substitute for a software engineering course – The activities need to be integrated in a coherent process, to make sense – Software development projects range from the very small to the very large... not all activities equally useful or relevant in any context spm - ©2014 adolfo villafiorita - introduction to software project management 2 Initiate Plan Execute & Close Monitor Assess Formalize Collect Close Feasibility Goals Outputs Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Overview Software development is a progressive refinement which moves from concept to operations through the following phases: – Requirements and User Experience Design – Design – Implementation – Verification and Validation – Deployment – Operations and Maintenance As we move along these phases, we make and commit to specific choices; the cost of changes increases accordingly Different processes put different emphasis on each activity or define the order in which these activities can be performed spm - ©2014 adolfo villafiorita - introduction to software project management 4 The software process Software Process: a coherent sets of activities for specifying, designing, implementing and testing software systems The software process manages the transition from concept to product A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective Some characteristics of a process: – the building blocks – the order in which the building blocks are executed – inputs/outputs to each activity – level of formality (when and how you move to the next activity; what you really need to trace) spm 5 The Building Blocks: the “what” Business/ Describes the environment (people, A textual Environment organization, other systems) in which the description, Modeling software in going to be run diagrams (BPMN, UML) Requirements Describes the external qualities of the A textual (the what) software (what the users sees) and the description, GUI constraints (for instance: execution layouts, use cases, environment) user stories,... spm 6 Example Business Modeling Requirements 1. Unit Head receives 1. The system shall allow a expense request unit head to authorize an expense request 2. Unit Head authorizes and forward to administration 2.... 3. Administration verifies budget availability and FURPS forwards to procurement - Functionality 4. Procurement proceeds - Usability - Reliability 5.... - Performance - Supportability spm 7 The Building Blocks: the “how” Architectural Describes how the system is structured in Diagrams (class, Design components components,...) (the how) Implementation Implementation of the requirements according to Code (the actual stuff!) the structure defined in the architectural design spm 8 Example (architectural diagrams) Several notations: Common goals: – Data flow diagrams – What components a system – Hierarchical decomposition is made of (logical/physical) – State diagrams – How they interact – Class diagrams – How they behave –... –... Show display Control Logic PersonLogic change_name change_surname Person Actuator Driver name surname get_fullname spm 9 The Building Blocks: “v&v” Verification It verifies that the the implementation works as A report (and the (does it work expected specification of the right?) tests - code or text) Validation It verifies whether the system does what was A report (and the (is it the right intended in the requirements specification of the thing?) tests - typically: text) Different scopes/representations: Different types: – unit (test a piece of code): – white box testing (you know the executable code source code) – component/system (test a – black box testing (you don’t know the internals) component): textual specifications/executable scripts spm 10 Examples Textual/Executable lists of tests Often in the form: – with the system in a given state – if some events occur (e.g. user interaction) – then some output is expected Example: – after successful login as a “simple user” – if the user presses the “admin” button it is taken to an error page displaying (“user is not authorized”) It can be automated (even with Graphical User Interfaces) spm 11 The Building Blocks: “going live” User User Manual and other information to support Manual! Documentation users about the functions and usage of the system Distribution and Activities related to going “live” and reaching the Software Installation Deployment customer package, Appstore, Website, Web Application,... Maintenance What you do after the software has been released (sometimes mentioned; modern software development approaches treat maintenance as a new project) spm 12 (Some) “Transversal Concerns” Business Plan How you are going to make money out of your Definition system Configuration The activities related to maintaining the coherency Items list, Management of a system when it evolves repository,... Project The activities to keep the project under control This course! Management Process Measuring your performances and making sure you Improvement get better at building software spm 13 Project Initiation: Feasibility and Project Authorization Initiating a project Goals of this Unit Learning qualitative and quantitative techniques to select among different projects Learning qualitative and quantitative techniques to choose the best alternative among different implementations of the same project Understanding how to write a Feasibility Study Choosing between internal development or external development (make or buy) spm - ©2014 adolfo villafiorita - introduction to software project management 2 How does a project start? Initiation by some stakeholder (a company, a potential customer,...) driven by a need (market, social, legal, technological advance,...) Boundaries and process not always clear or very formalized First activities performed to: – Agree on the goals (scope) – Understand value and risks (for the performing organization and for the other stakeholders) – Choose a project approach spm - ©2014 adolfo villafiorita - introduction to software project management 3 Initiate Plan Execute & Close Monitor Assess Formalize Collect Feasibility Goals Outputs Close Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Project Value and Risks Project Value and Risks Two main characteristics determine whether a project is worth starting: – The value generated by the project – The risks associated to the project The meaning of value and risk depend upon many factors Value and risks can be assessed qualitatively or quantitatively Sound assessments are difficult, given the unpredictability of projects (and of the world) Garbage in = Garbage out spm - ©2014 adolfo villafiorita - introduction to software project management 6 Project Value and Risks Project Value: – Direct and indirect value generated by the project – Sustainability of the project outputs – Alignment with strategic objectives of an organization Project Risks – Resource availability – Timing – Technical difficulties and uncertainties spm - ©2014 adolfo villafiorita - introduction to software project management 7 Value: Direct and Indirect Value Direct and Indirect Value measures the positive and negative outcomes of a project and its outputs Some metrics to consider include: – Revenues, both direct and indirect – Social and environmental impact – Image and publicity – Know-how acquired Direct and indirect value are strictly related to the business model and to the sustainability of the project outputs (see next slide) spm - ©2014 adolfo villafiorita - introduction to software project management 8 Value: Sustainability Sustainability refers to the capacity of sustaining the project and its outputs after the project end Taking into account the operational costs of a project’s outputs and the way in which the project outputs will survive after a project end is an important consideration to understand whether a project is worth starting. Often overlooked, especially when project execution generates revenues spm - ©2014 adolfo villafiorita - introduction to software project management 9 Value: Alignment with the Strategic Objectives The alignment with the strategic objectives measures how important and relevant a project is for the performing organization Priority, resource assigned, internal support, opportunities for the project team after the project end are all affected by how strategic a project is for an organization spm - ©2014 adolfo villafiorita - introduction to software project management 10 Risks: Resource Availability Projects require the availability of human, financial, and technical resources in specific time-frames Although it might be difficult to preempt the resources in advance, a check on the projects needs is a good sanity-check Some aspects to consider include: the required resource, current load and availability, projections on future load and availability, priority and importance of the project spm - ©2014 adolfo villafiorita - introduction to software project management 11 Risks: Timing Many projects have specific time-windows for the delivery of their outputs Deliver too early or too late and the outputs of the project might be useless Consider, for instance, the race of competing firms in delivering similar products spm - ©2014 adolfo villafiorita - introduction to software project management 12 Risks: Technical Difficulty and Uncertainty The success of many projects relies on the actual capability of solving various technical challenges, when the time comes Understanding what these challenges are is an important factor in determining the risks associated to a project spm - ©2014 adolfo villafiorita - introduction to software project management 13 Techniques to Assess Value and Risks Payback Period The payback period is the time taken to gain a financial return equal to the original investments – Measured in months or years – When using the payback period the projects/options that minimize the payback period are chosen in favor of the others spm - ©2014 adolfo villafiorita - introduction to software project management 15 Example Project A Project B Project C Year 0 € (50,000.00) € (20,000.00) € (15,000.00) Year 1 € 30,000.00 € (10,000.00) € 15,000.00 Year 2 € 30,000.00 € 10,000.00 € 1,000.00 Year 3 € 1,000.00 € 60,000.00 Year 4 € 1,000.00 € 50,000.00 Expenses € (50,000.00) € (30,000.00) € (15,000.00) Gains € 62,000.00 € 120,000.00 € 16,000.00 Profit € 12,000.00 € 90,000.00 € 1,000.00 Payback 2 years 3 years 1 year Remark: accounting style notation. Negative numbers in red and in parentheses spm - ©2014 adolfo villafiorita - introduction to software project management 16 Discussion Advantages – Simple, readily available data – It reduces exposure to risk – Particularly effective in high-technology/fashion projects – It favors shorter term benefits Disadvantages – Difficult to use on longer term projects – Based only on cash flows – Does not quantify exposure to risk – Does not look at total gains spm - ©2014 adolfo villafiorita - introduction to software project management 17 Payback Weaknesses Different projects might have the same the same payback period, but different profiles in returning of the investments These profiles are not taken into account by the technique but could make the different between two projects spm - ©2014 adolfo villafiorita - introduction to software project management 18 Payback Weaknesses Same payback period, but Project A gets more money first (and reduces risks) Year Project A Project B Year 0 € (10,000.00) € (10,000.00) Year 1 € (5,000.00) € (5,000.00) Year 2 € 10,000.00 € 5,000.00 Year 3 € 5,000.00 € 10,000.00 spm - ©2014 adolfo villafiorita - introduction to software project management 19 Payback Weaknesses Diﬀerent payback periods, Project B earlier but gets less money Year Project A Project B Year 0 € (10,000.00) € (10,000.00) Year 1 € (5,000.00) € (5,000.00) Year 2 € 5,000.00 € 5,000.00 Year 3 € 5,000.00 € 11,000.00 Year 4 € 20,000.00 spm - ©2014 adolfo villafiorita - introduction to software project management 20 Return on Investment (ROI) ROI calculates the average annual profit and transforms it into a percentage of the total investments Profit = Returns - Investments Annual Profit = Profit / Duration ROI = Annual Profit / Investments When using ROI, choose the project with the highest ROI spm - ©2014 adolfo villafiorita - introduction to software project management 21 Example Suppose we have the following projections for a project we need to decide whether to start or not Project A Project B Project C Year 0 € (50,000.00) € (20,000.00) € (15,000.00) Year 1 € 30,000.00 € (10,000.00) € 15,000.00 Year 2 € 30,000.00 € 10,000.00 € 1,000.00 Year 3 € 1,000.00 € 60,000.00 Year 4 € 1,000.00 € 50,000.00 spm - ©2014 adolfo villafiorita - introduction to software project management 22 Example Project A – Profit = 62000 - 50000 = 12000 – Annual Profit = 12000 / 4 = 3000 – ROI = 3000 / 50000 = 6% Project B – Profit = 120000 - 30000 = 90000 – Annual Profit = 90000 / 4 = 22500 – ROI = 22500 / 30000 = 75% Project C – Profit = 16000 - 15000 = 1000 – Annual Profit = 1000 / 2 = 500 – ROI = 500 /15000 = 3% SOLUTION: Project B (highest ROI) spm - ©2014 adolfo villafiorita - introduction to software project management 23 Discounted Cash Flows/Inflation The value of money decreases over the years (inflation!) according to the inverse compound interests formula Discount Factor = 1 (1 + i)n Thus, giving it the money we invest now the same weight of money we will get in five year is over optimistic DCF (Discounted Cash Flows) are techniques that take into account inflation Curiosity: where does inflation comes from? Answer: Debasement A nice reference: http://en.wikipedia.org/wiki/Inflation spm - ©2014 adolfo villafiorita - introduction to software project management 24 Net Present Value Net Present Value discounts sums in the future in order to provide a more realistic comparison between presents investments and future gains spm - ©2014 adolfo villafiorita - introduction to software project management 25 Net Present Value Example Hypothesis 1 Discount Rate: 10% Discount Factor = (this is “i”) (1 + i)n Year (n) Cash Flow Discount Factor Present Value 0 € (35,000.00) 1.00 € (35,000.00) 1 € 10,000.00 0.91 € 9,090.91 2 € 15,000.00 0.83 € 12,396.69 3 € 20,000.00 0.75 € 15,026.30 Expenditure € (35,000.00) € (35,000.00) Gains € 45,000.00 € 36,513.90 Profit € 10,000.00 € 1,513.90 spm - ©2014 adolfo villafiorita - introduction to software project management 26 Net Present Value: Discussion Advantages – More accurate profit-loss data Disadvantages – It uses a fixed discount rate (may be unrealistic) – It favors shorter terms projects spm - ©2014 adolfo villafiorita - introduction to software project management 27 Score Matrices The financial methods (Payback, ROI, NPV) look only at some of the financial data Scoring matrices allow one to take into account other factors They are based on a standardized set of criteria and weights, which highlight the relevant features of a project A qualitative evaluation of how a project scores with respect to each criteria positions the project on a scale and helps compare it with past or competing projects spm - ©2014 adolfo villafiorita - introduction to software project management 28 Score Matrix Example Factor Value Weight SUM Comment The project aligns with the strategic YES 2 2 objectives The project has a profit > 20% NO 4 0 Payback period < 2 years YES 5 5 Enlarges the customer base YES 2 2 The project requires a standard NO 3 0 technology The quality constraints are simple YES 1 1 to meet The timing is not too tight NO 4 0 We have skilled personnel to do the YES 5 5 work 15 – Value can be binary (YES/NO) or a number (e.g. from 1 to 5) and measures how well the project meets the requirement – The weight measures how important a factor is for the decision spm - ©2014 adolfo villafiorita - introduction to software project management 29 Figure 2-9. Sample Weighted Scoring Model for Project Selection Criteria Weight Trip 1 Trip 2 Trip 3 Trip 4 Total cost of the trip 25% 60 80 90 20 Probability of good weather 30% 80 60 90 70 Fun activities nearby 15% 70 30 50 90 Recommendations 30% 50 50 60 90 Weighted Project Scores 100% 64.5 57.5 75 66.5 Weighted Score by Project Trip 4 Trip 3 Trip 2 Trip 1 0 20 40 60 80 !" Discussion Advantages – Simple – It encourages standardization and more objectivity in decision making – It helps discuss and evaluate the project characteristics – It widens the range of evaluation – Not biased toward shorter term projects Disadvantages – A simple model may encourage development of long and useless lists – Different factors have same importance (unless the weight matrix is used) spm - ©2014 adolfo villafiorita - introduction to software project management 31 Caveat – Not all score matrices are equally good. – The following is an example of a bad matrix. Why? Factor Value Weight SUM Comment The project has a profit > 20% YES 3 3 The project is highly risky NO 3 0 3 SOLUTION As a consequence an highly risky project is preferred over a project which is not very risky A positive factor (first row) and a negative factor (second row) influence in the same way the matrix spm - ©2014 adolfo villafiorita - introduction to software project management 32 Caveat Make sure the questions either all positively influence or all negatively influence the decision or use scores with different signs! spm - ©2014 adolfo villafiorita - introduction to software project management 33 SWOT analysis Technique credited to Albert Humphrey Systematic analysis of: – Strengths – Weaknesses – Opportunities – Threats... to understand the feasibility of a project and/or come out with achievable project goals Often presented as a 2x2 matrix, with each cell listing all elements of a given type (see next slide) spm - ©2014 adolfo villafiorita - introduction to software project management 34 Source: http://en.wikipedia.org/wiki/File:SWOT_en.svg (cc license) SWOT: Some factors to consider Strengths: Weaknesses: – Competences – Disadvantages – Selling points – Methodology –... – Timing – Capability Gaps Opportunities: Threats: – Market and Industry – Market and Industry trends trends – Competing technologies – Weaknesses of – Sustainability competitors spm - ©2014 adolfo villafiorita - introduction to software project management 36 Figure 2-2. Mind Map of a SWOT Analysis to Help Identify Potential Projects (Created with MatchWare’s MindView Business Edition) !# Stakeholder Analysis Goal: understanding who are the project stakeholders and the influence they have on the project Different techniques available One technique organizes stakeholders in a 2x2 matrix in which: – one dimension measures the power a stakeholder can exert (low or high) – the other dimension measures the interest a stakeholder has in a project (negative or positive) This allows to define specific management policies for the different stakeholders spm - ©2014 adolfo villafiorita - introduction to software project management 38 Stakeholder Analysis Assessing Sustainability The analysis is meant to understand the operational costs of a project’s output Sometimes a specific project activity. A preliminary sustainability analysis, however, can help choose among different project implementations Some aspects to consider include the business model and the break-even point spm - ©2014 adolfo villafiorita - introduction to software project management 40 The Feasibility Study Feasibility Study The feasibility study is the document that allows to formally authorize a project and to link it to the organization’s goals – Wide range of outputs: from a few to hundreds of pages (according to complexity and formality) – The feasibility study can be thought of as a project in the small, drafting the main information we will define in more details during the project – Basis for project selection: Management must choose what projects to activate. spm - ©2014 adolfo villafiorita - introduction to software project management 42 Goals of a Feasibility Study Identify: – the project goals – the project constraints Assess value and risks (using the techniques above) Ensure the project lines up with – the customer objectives – the performing organization objectives Demonstrate that the project goals – can be achieved respecting the quality, cost, and time constraints spm - ©2014 adolfo villafiorita - introduction to software project management 43 Feasibility Document: Structure – A statement of work, which – An analysis of the describes what the project will stakeholders. accomplish. – The project risks. – The business objectives – Possible alternatives to the (value) of the project or its project, such as a make or outputs and information about buy decision. the business model, if relevant. – An evaluation of the project – A summary of the project and of the alternatives, using budget, which forecasts the techniques described expenses and incomes. above. – A summary of the project milestones, that is, a rough schedule of the project identifying the most important events. spm - ©2014 adolfo villafiorita - introduction to software project management 44 Feasibility: Additional Considerations The feasibility document has a value for: – The client, since it helps understand the way forward and what are the short and long term perspectives – The performing organization, since it helps understand whether it makes sense to move on with a project – The project manager, since it helps understand whether the project will be in the manager’s comfort zone or not (and take an informed decision on whether the project is worth taking or not) spm - ©2014 adolfo villafiorita - introduction to software project management 45 The Project Approval Process The process which brings to the project approval is more or less structured according to the practices of the performing organization It is organized in the following steps: – Upon receiving a request, identify a (preliminary) project manager – The project manager prepares a feasibility study which is agreed with the customer and key stakeholders – The project manager submits the document for authorization – The document is analyzed and a formal decision is taken – The project manager is appointed and the project moves to the planning phase spm - ©2014 adolfo villafiorita - introduction to software project management 46 Developing a Project Charter After deciding what project to work on, it is important to let the rest of the organization know A project charter is a document that formally recognizes the existence of a project and provides direction on the project’s objectives and management Key project stakeholders should sign a project charter to acknowledge agreement on the need and intent of the project; a signed charter is a key output of project integration management Information Technology Project Management, Eighth Edition 47 Inputs for Developing a Project Charter A project statement of work A business case Agreements Enterprise environmental factors Organizational process assets, which include formal and informal plans, policies, procedures, guidelines, information systems, financial systems, management systems, lessons learned, and historical information Information Technology Project Management, Eighth Edition 48 Table 4-1. Project Charter for the DNA- Sequencing Instrument Completion Project Information Technology Project 49 Management, Eighth Edition Table 4-1. Project Charter (cont.) Information Technology Project Management, Eighth Edition 50 Project Integration Management and Scope Management Project Integration Management Project integration management involves coordinating all the project management knowledge areas throughout a project’s life span The main planning output is a project management plan ! Project Integration Management Project Charter Project Management Plan Project Management Plans A project management plan is a document used to integrate and coordinate all project planning documents and to help guide a project’s execution, monitoring and control, and closure Plans created in the other knowledge areas are subsidiary parts of the overall project management plan and provide more detailed information about that knowledge area Project management plans facilitate communication among stakeholders and provide a baseline for progress measurement and project control A baseline is a starting point, a measurement, or an observation that is documented so that it can be used for future comparison " Common Elements in Project Management Plans Introduction/overview of the project Project organization Management and technical processes (including project lifecycle description and development approach, as applicable) Work to be performed (scope) Schedule information Budget information References to other project planning documents # Figure 4-3. Sample Project Management Plan (Partial) Management Processes Management Review Process: The project steering committee will meet at least monthly to provide inputs and review progress on this project. Progress Measurement Process: The project steering committee will review project progress during project review meetings, and they can also review information as needed by viewing reports on the enterprise project management software. Post project progress will also be measured to see if the project met its goals. These goals include reducing the training cost per employee by $100/person/year and receiving positive results from survey participants on the effectiveness of the training. Change Approval Process: See Attachment 1 based on corporate standards. Supplier Management Process: See Attachment 2 based on corporate standards. Technical Processes Enterprise Project Management Software: All tasks, costs, resources, issues, and risks will be tracked for this project using our enterprise project management software. Data must be entered on a weekly basis, at a minimum, to provide timely information. Supplier Evaluation: The project team will coordinate with the purchasing department to follow our standard procedures for selecting and working with suppliers. See Attachment 2 for corporate standards. Productivity Improvement: The project team will work with the finance and quality assurance departments to develop and implement a system to measure improvements in employee productivity that result from this new training program. The finance department will report on this information annually beginning one year after the first new training course is offered. $ Initiate Plan Execute & Close Monitor Assess Formalize Collect Feasibility Goals Outputs Close Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Project Scope Management Plan Scope Management Project Scope Management Project scope management involves defining and controlling what work is or is not included in a project The main planning tasks include planning scope management, collecting requirements, defining scope, and creating the WBS The main documents produced are requirements documents, a requirements management plan, a requirements traceability matrix, and a scope baseline, which is composed of an approved scope statement, a WBS, and a WBS dictionary Formalizing the Project Goals Defining the project goals (project scope) is one of the first and most important activities in a project The project scope: – Ensures that the project includes all and only the work necessary – Establishes a baseline of the work to be performed. – Defines a reference document for project acceptance. The definition of the project scope starts during the feasibility study The project goals and the alignment of a project with its scope continues throughout the lifecycle of a project spm - ©2014 adolfo villafiorita - introduction to software project management 14 Project Scope Document The project scope is fixed in the project scope document, which contains: – Project goals and requirements, which describe what we intend to achieve with the project and the main characteristics of the project and its outputs – Assumptions and constraints, which describe the conditions which have to be met for the project to succeed – Project outputs and control points, which describe the outputs of the project, and in some cases, a rough timing of their delivery spm - ©2014 adolfo villafiorita - introduction to software project management 15 Project Goals and Requirements The project goals and requirements are the basis to define: – The baseline work to be performed (compare Work Breakdown Structure and Change and Configuration Management) – The project acceptance criteria (compare Project Closing and Quality Management) Strictly related to the software requirements Sometimes useful to include also what is outside the scope of a project spm - ©2014 adolfo villafiorita - introduction to software project management 16 Project Objectives/Goals Make the objectives SMART! Specific Realistic – Clear and concise – Goals must be realistic. Unrealistic goals set unrealistic Measurable expectation and make the – Easy to obtain measure to team apathetic. understand whether the goal has been reached. Maybe a Time-bound date or a number, or a formula – Must have a begin and an end. (but keep it simple!) If no end can be set, are you sure we are not talking about Agreed-to operational work? – Goals must be specific enough that the team can agree on being able to reach them spm - ©2014 adolfo villafiorita - introduction to software project management 17 Project Objectives/Goals Make the objectives... russian (MoSCoW)! M: Must Have C: Could Have – essential – desirable S: Should Have W: Won’t Have – important, but – we will not do we can do them (next without iteration) spm - ©2014 adolfo villafiorita - introduction to software project management 18 Project Objectives/Goals Try and make sure class M success criteria depend on factors under your/or the project’s control Negative examples (M not under control of the PM): – The system will have 1,000 users in the first month. (What tools does the PM have to ensure achievement of this goal?) – The data entry speed of users will increase tenfold. (How can the PM ensure the tenfold increase is actually achieved?)... Sometimes a matter of wording. The consequences might be costly, nevertheless. spm - ©2014 adolfo villafiorita - introduction to software project management 19 Assumptions Assumptions are conditions which are considered to be true, but might not in fact be Assumptions are not under the control of the project manager, but they might be under the control of some project stakeholders When this is the case, assumptions can be used to define duties and obligations of project stakeholders Constraints are known limitations. They explain why we set some goals and not others and why we structure the work in some way rather than another. spm - ©2014 adolfo villafiorita - introduction to software project management 20 Project Outputs (Milestones and Deliverables) The project outputs define what a project will accomplish and when Milestone: a significant event in the project – Identify critical points in the project and in the schedule – Often used at “review” or “delivery” times – Can be tied to contractual terms, calendar constraints, deliverables Deliverable: a unique, measurable, and verifiable work product – Can be internal or external – Can have different dissemination and formality levels – In Gantt charts they often interconnect tasks (the output of task is a deliverable which is the input of a subsequent activity) … in current practice often milestone and... both have zero deliverable are used interchangeably duration in the plan (both used to identify products - milestones may represent key-products) spm - ©2014 adolfo villafiorita - introduction to software project management Planning Scope Management The purpose of the process of planning scope management is to determine how the project scope will be defined, validated, and controlled. Validation means formal acceptance of deliverables by the customer and other identified stakeholders In contrast, verification (done as part of controlling quality) means the deliverable complies with a regulation, requirement, specification, or imposed condition Project teams usually have several meetings with key stakeholders and experts to help them develop a scope management plan and requirements management plan. Project Scope Management Collect Requirements Collecting Requirements The PMBOK® Guide – Seventh Edition, defines a requirement as “a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.” A requirements management plan describes how project requirements will be analyzed, documented, and managed. !" Figure 4-4. Sample Requirements Management Plan (partial) Requirements Management Plan Version 1.0 September 30 Project Name: Just-In-Time Training Project Planning, tracking, and reporting requirements Information from the Phase I project, the business case, and the project charter will provide valuable information in determining requirements for this project, as will many existing corporate standards and processes. A survey will also be used to gather requirements. All requirements will be documented where appropriate. For example, requirements related to course prerequisites will be documented in course descriptions. Requirements related to facilities, class size, etc. will be documented in the scope statement. Requirements will be tracked by the person in charge of each related deliverable and reported as part of our normal reporting processes (i.e., weekly status reports, monthly review meetings, etc.) Performing configuration management activities Requirements can be introduced by several means, such as existing written requirements, suggestions provided from our survey, or direct suggestions from stakeholders. Appropriate project stakeholders will analyze, authorize, track, and report changes to requirements. The project manager must be informed in advance of potential changes to requirements and be involved in the decision process to approve those changes. Any change that will impact the project’s cost or schedule significantly must be approved by the project steering committee. Prioritizing requirements All requirements will be designated as 1, 2 or 3, for mandatory, desirable, or nice-to-have, respectively. Emphasis will be placed on meeting all mandatory requirements, followed by desirable and then nice-to- have requirements. Using product metrics Tracing requirements Outputs of Collecting Requirements Requirements documents, which can range from a single-page checklist to a room full of notebooks with text, diagrams, images, etc. A requirements traceability matrix (RTM), which is a table that lists requirements, various attributes of each requirement, and the status of the requirements to ensure that all of them are addressed Figure 4-5. Sample Requirements Traceability Matrix Require- Name Category Source Status ment no. R26 Survey Survey Project Complete. The questions steering survey questions committee were reviewed and minutes approved by the steering committee. R31 Course Assessment Corporate In process. The evaluations training course evaluations standards have not been created yet. Define Scope Defining Scope Good scope definition is crucial to project success because it: Helps improve the accuracy of time, cost, and resource estimates Defines a baseline for performance measurement and project control Aids in communicating clear work responsibilities A project scope statement describes product characteristics and requirements, user acceptance criteria, and deliverables. Work that is not included in the scope statement should not be done, and you can explicitly state what is out of scope for the project under a section called project exclusions. Figure 4-6. Sample Scope Statement (continued) Deliverables Project Management-Related Deliverables Project charter, project management plan, scope statement, WBS, etc. Product-Related Deliverables: 1. Supplier management training: 1.1. Needs assessment: A survey will be conducted to determine the learning objectives for the executive, introductory, and advanced courses. The corporate online survey software will be used and coordinated with IT and HR. Results will be documented in a detailed report (8-10 pages) and presentation (15-20 minutes long). 1.2 Research of existing training: A study will be done to identify current training courses and materials available. Results will be documented in a detailed report and presentation. 1.3. Partnerships: Partnership agreements will be explored to get outside training organizations and suppliers to work on developing and providing training. 1.4. Course development: Appropriate materials will be developed for each course. Materials could take various formats, including written, video, DVD, or Web- based. Materials should include interactivity to keep learners engaged. 1.5. Pilot course: A pilot course will be provided for the introductory supplier management course. Feedback from the pilot course will be incorporated into following courses. Keep Scope Information Current The project team should update the project scope statement as new information becomes available Name different iterations of the scope statement Version 1.0, Version 2.0, etc. A good, up-to-date scope statement helps prevent scope creep, which is the tendency for project scope to continually increase Deciding the work to be Performed (Work Breakdown Structure) Project Scope Management Create WBS Goals of the Unit Understanding the transition from project goals to the project schedule Introducing the Work Breakdown Structure notation spm - ©2014 adolfo villafiorita - introduction to software project management 2 Initiate Plan Execute & Close Monitor Assess Formalize Collect Feasibility Goals Outputs Close Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management What is a WBS? A Work Breakdown Structure (WBS for short) is a (deliverable-oriented) hierarchical decomposition of the work to be executed by the project team to accomplish projects objectives and create the required deliverable spm - ©2014 adolfo villafiorita - introduction to software project management 4 WBS Example 1 Software System 1.1 1.2 1.3 1.4 1.5 1.6 Configuration Main Mobile Client Appstore Dev. Tools User Manual Management Requirements Development Deployment Procurement 1.3.1 1.3.2 1.3.3 1.3.4 Detailed Architecture Code Tests Requirements 1.3.4.1 1.3.4.2 1.3.4.3 Unit System Integration Tests Tests Tests spm - ©2014 adolfo villafiorita - introduction to software project management 5 WBS: Remarks Two formats – Graphical tree (Vision, Graffle, LibreOffice,...) – Textual outline (MS Word, Text Editor, Outliner,...) Uses a decimal numbering system to identify elements (Ex: 3.1.5) Shows “is contained in” relationships Does not show dependencies nor durations spm - ©2014 adolfo villafiorita - introduction to software project management 6 Why is it useful? A WBS establishes the basis for: – Defining the work to be performed in a project – Showing how various activities are related to the project objectives – Establishing a framework for defining, assigning, and monitoring work and costs – Identifying the organizational elements responsible for accomplishing the work spm - ©2014 adolfo villafiorita - introduction to software project management 7 WBS Rules of the Thumb Everything (and nothing else) is in place: – The 100% rule: make sure all work items are there (product oriented WBS are better suited for this kind of rule) – The ME rule (Mutually Exclusive rule): make sure there are no overlaps in the definition of the elements (see coupling, below) – No need to make it balanced: all paths do not have to go to the same level Quality of the WBS is high (*) – Coh

Software Project Management (SPM) Week 1 Notes PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue