Click here to load reader

CSCI 3428: Software Engineering Tami Meredith Chapter 3 Planning and Managing the Project

Embed Size (px)

DESCRIPTION

Process Management Goal: To use the available resources to produce a piece of software on time and within the budget. A. Identify, mitigate, and control risks B. Produce a plan to achieve the goal if it can be reached C. To provide clients with accurate time and cost assessments

Citation preview

CSCI 3428: Software Engineering Tami Meredith Chapter 3 Planning and Managing the Project Software Development (Actual) Process Management Goal: To use the available resources to produce a piece of software on time and within the budget. A. Identify, mitigate, and control risks B. Produce a plan to achieve the goal if it can be reached C. To provide clients with accurate time and cost assessments Terms Activity: Part of the project Milestone: The completion of an activity Deliverable: Something we must produce, e.g., documents, demonstrations, test completion What are we doing, when must we be done, what is the result? Note: CISY 4425 focuses heavily on the material of Chapter 3. Problems We can't properly estimate time/costs for a later stage (e.g., implementation) until earlier stages (e.g., requirements, design) are completed. Software development is very dynamic, things change very quickly: Customer needs, requests Libraries, tools, languages, hardware Often encounter unexpected difficulties (e.g., harder to program than expected) S/W development is iterative and the number of iterations is often unpredicatable Its so complex and difficult that in the text, Tables and Figures use House Building The Critical Path Method Draw a hammock graph of all activities An activity must be completed before the one below can be started Branches exist when two activities can be done at the same time (in parallel) Examining paths will show us: Bottlenecks Minimum time we need (longest path) See Figure 3.3 for an example Gantt Charts A type of work breakdown structure Often used in automated project management tools Useful for seeing the plan, but not progress or resource management Usually supplemented with some sort of personnel tracking Personnel Characteristics Ability to do the job Interest (motivation) Experience with: Application domain Tools, Language, Environment Similar coding assignments Education and training Personal skills (Good managers are intuitive psychologists) Ability to communicate, communication style Ability to work well with others, work style Leadership and management skills Lines of Communication Each line of communication adds the chance for communication failure For n workers heterarchy, the number of lines = (n*(n-1))/2 E.g.: 6 workers = (6*5)/2 = 15 hierarchy, the number of lines = n-1 E.g.: 6 workers = (6-1) = 5 Work Styles (Personality) Jungian Precursor of the MBPI (Myers-Briggs) 1) Extroversion:Introversion 2) Sensing:Intuition 3) Thinking:Feeling 4) Judging:Perception Intuitive Introvert asks, emotional Intuitive Extrovert tells, emotional Rational Introvert asks, logical Rational Extrovert tells, logical Productive Meetings Clear purpose (actually needed) Prepared attendees Everyone needed is there Conversation stays on topic Decisions made are actually applied All participants generally participate equally LESS IS MORE! Reasons for Inaccurate Estimates User requested changes Forgotten tasks Users not knowing what they want/need Estimate based on insufficient analysis Lack of control during development Bad techniques for performing estimation Key Influences on Estimates Application complexity (system, programs) Integration with existing systems (e.g., DBMS) Capabilities of team members skills experience with application experience with programming language/tools experience with hardware Frequency/impact of client-requested changes Size of development team Extent of documentation/standards Availability of tools Estimation Techniques Expert Assessment Subject to human error Algorithmic Techniques Very large number of variables Corporate Culture Programming Language Application Complexity Programmer Experience Re-use Opportunity Project Size Machine Learning Techniques Require a modest training set to be useful Risks A risk is an unwanted event with negative consequences Some variation in the likelihood of occurring (risk probability) Problem = Probability of 1.0 Possible variation in the amount of damage (risk impact) Degree to which we can influence probability (risk control) Can be generic or project-specific Most Common Risks Personnel shortfalls Unrealistic schedules and budgets Developing the wrong software Creating the wrong user-interface Gold plating Requirements changes Failures of external (e.g., subcontracted) tasks or components Performance failures Exceeding the state-of-the-art Risk Management (Figure 3.15) Assessment Identification Checklist, decomposition, assumption analysis, decision driver analysis Analysis System dynamics, performance, cost, network, decision, quality factors Prioritisation Exposure, compound effects Control Reduction Buying information, avoidance, transfer, leverage, development process Planning Element planning, plan integration Resolution Mitigation, monitoring/reporting, re-assessment Project Plan (consists of) 1) Project scope 2) Project schedule 3) Team organisation 4) Technical description 5) Proposed standards, procedures, techniques, and tools 6) Quality assurance plan 7) Configuration management plan 8) Documentation plan 9) Data management plan 10) Resource management plan 11) Test plan 12) Training plan 13) Security plan 14) Risk management plan 15) Maintenance plan Plan Details Algorithms Tools Review/Inspection techniques Specification languages and representations Design languages and representations Coding languages Testing techniques COTS components, Libraries Professionalism What do you do when you think the boss/plan/spec is wrong? Do you do something immoral/illegal because you are told to do it (e.g., "borrow" code)? What happens if you have to do something you don't want to do (e.g., paired programming)? What happens if you see a colleague messing up? What do you do if you totally screw up and realise you made a mistake? Famous Moments in Software Engineering The USS Yorktown Ticonderoga Class Guided Missile Cruiser On 21 September 1997, while on manoeuvres off the coast of Virginia, a crew member entered a zero into a database field causing a divide by zero error in the ship's Remote Data Base Manager which brought down all the machines on the network, causing the ship's propulsion system (engines) to fail. It was towed back to port... Network of 27 dual 200 MHz Pentium Pro machines running Windows NT 4.0 communicating over fiber-optic cable to a Pentium Pro-based server