112. Processes Agenda for processes r1. Organizations r2. Integrated product teams (IPTs) r3. Integrated process teams r4. Processes r5. Methods r6. Intranet.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Lecture 2 Team Coordination 1 ICS 126 Team Coordination Team Formation and Organization Group Management Meeting Techniques Large software systems require.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
How to Document A Business Management System
Project Perfect Pty Ltd Project Administrator Overview of Software.
SESSION 10 MANAGING KNOWLEDGE FOR THE DIGITAL FIRM.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
System Design and Analysis
Knowledge Acquisition CIS 479/579 Bruce R. Maxim UM-Dearborn.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
SDLC. Information Systems Development Terms SDLC - the development method used by most organizations today for large, complex systems Systems Analysts.
James A. Senn’s Information Technology, 3rd Edition
CSC230 Software Design (Engineering)
Configuration Management
The Agile vs. Waterfall Methodologies Systems Development:  the activity of creating new or modifying / enhancing existing business systems.  Objectives.
Review an existing website Usability in Design. to begin with.. Meeting Organization’s objectives and your Usability goals Meeting User’s Needs Complying.
Planning. SDLC Planning Analysis Design Implementation.
Welcome to CMPE003 Personal Computer Concepts: Hardware and Software Winter 2003 UC Santa Cruz Instructor: Guy Cox.
Software Configuration Management
Introduction to Computer Technology
What is Business Analysis Planning & Monitoring?
Introduction to Systems Analysis and Design Trisha Cummings.
Systems Analysis and Design: The Big Picture
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Chapter 10.
Requirements Analysis
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Software System Engineering: A tutorial
CSE 303 – Software Design and Architecture
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
2Object-Oriented Analysis and Design with the Unified Process The Requirements Discipline in More Detail  Focus shifts from defining to realizing objectives.
Service Transition & Planning Service Validation & Testing
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
© 2001 Business & Information Systems 2/e1 Chapter 8 Personal Productivity and Problem Solving.
Lead Black Slide Powered by DeSiaMore1. 2 Chapter 8 Personal Productivity and Problem Solving.
8. Processes1 Agenda for Processes q1. Organization q2. Processes q3. Methods q4. Environment q5. Tools.
1 Agenda for processes r1. Organizations r2. Integrated product teams (IPTs) r3. Integrated process teams r4. Processes r5. Process work products.
SE: CHAPTER 7 Writing The Program
The Systems Development Life Cycle
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Systems Analysis and Design in a Changing World, Fourth Edition
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Meeting Management/Planning. Today Go over basics of meeting management Introduce key elements of creating a plan.
10. Applications1 Applications Agenda (1 of 2) r1. Introduction r2. Example r3. Simple products r4. Classical development r5. Incremental builds r6. Spiral.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
1 Agenda for implementation of PBDA r1. Optimization of product development r2. Heuristics r3. Application notes r4. Questions to identify risks.
State of Georgia Release Management Training
SCOPE DEFINITION,VERIFICATION AND CONTROL Ashima Wadhwa.
Modern Systems Analysis and Design Third Edition Chapter 2 Succeeding as a Systems Analyst 2.1.
Copyright 2007, Information Builders. Slide 1 iWay Web Services and WebFOCUS Consumption Michael Florkowski Information Builders.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
10-1 McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Managing Multiple Projects Steve Westerman California Department of Motor Vehicles Steve Young Mathtech, Inc.
Fall CS-EE 480 Lillevik 480f06-l7 University of Portland School of Engineering Senior Design Lecture 7 Functional specifications Technical meetings.
 System Requirement Specification and System Planning.
Software Project Configuration Management
Information Systems Development
Fundamentals of Information Systems, Sixth Edition
Software Configuration Management
Chapter 18 Maintaining Information Systems
TechStambha PMP Certification Training
Systems Analysis and Design
Introduction to Systems Analysis and Design
Introduction to Systems Analysis and Design Stefano Moshi Memorial University College System Analysis & Design BIT
CHAPTER 9 (part a) BASIC INFORMATION SYSTEMS CONCEPTS
Presentation transcript:

112. Processes Agenda for processes r1. Organizations r2. Integrated product teams (IPTs) r3. Integrated process teams r4. Processes r5. Methods r6. Intranet

212. Processes 1. Organizations rNumber rTypes of groupings rTypes of project organizations 1. Organizations

312. Processes Number rLarge number of organization types are possible rMore than one type may be present on a project at one time 1. Organizations

412. Processes Types of groupings rProject -- The grouping of people to accomplish the project rCompany --The grouping of people by companies rAdministrative -- The grouping of people within a company for personal development 1. Organizations

512. Processes Types of project organizations (1 of 4) rFunctional -- The grouping of people is along functional lines rProduct -- The grouping of people is by product and process rCombination -- The grouping of people is a combination of functional and product 1. Organizations

612. Processes Types of project organizations (2 of 4) Management BusinessI&T System Engineering Development 1. Organizations Example of functional project organization

712. Processes Types of project organizations (3 of 4) Level 1 Product Team Level 2 Product Team 1 Level 2 Product Team 2 Level 2 Product Team 3 Level 3 Product Team 2 Level 3 Product Team 3 1. Organizations Example of product project organization

812. Processes Types of project organizations (4 of 4) Management Business Processes Level 1 Product Team Level 2 Product Team 1 Level 2 Product Team 2 Level 2 Product Team 3 Level 2 Product Team 2 Level 2 Product Team 3 Example of combined project organization

912. Processes 2. Integrated product teams (IPTs) rDefinition rIPT organization rOrganization guidelines rOrganization limitations rSize of IPTs rCommunication among IPTs 2. Integrated product teams

1012. Processes Definition rHave the capability to do a turn-key job in producing a product rHave work teams and resources Work teams are dedicated teams devoted to the product Resources are people who may provide services to several IPTs Organization is usually functional 2. Integrated product teams

1112. Processes IPT organization Product Management Business System Engineering Mechanical Engineering Electrical Engineering Conf MgtReliabilityManufacturingQuality Computer Engineering Work Teams Resources 2. Integrated product teams

1212. Processes Organization guidelines rOrganize teams in the same way as the spec tree rAssign RAA for any one product to a single IPT rOK for an IPT to have RAA for multiple products rDon’t give multiple IPTs RAA for a single product rReduce coupling between IPTs 2. Integrated product teams

1312. Processes Organization limitations rOrganization may be chosen for economic, personnel, or other reasons. rOrganization may not be optimum for execution rRegardless of the organization, the product engineers have RAA to make the product work 2. Integrated product teams

1412. Processes Size of IPTs r5-20 people rEnsure stakeholders satisfaction 2. Integrated product teams

1512. Processes Communications among IPTs rIPTs need to agree upon information communicated between products Description, schedule, and RAA for items to be sent between IPTs Communication between engineers on common issues 2. Integrated product teams

1612. Processes 3. Integrated process teams rDefinition rProcess teams and IPTs rProcess team domain rProcess team types rProcess team reporting options 3. Integrated process teams

1712. Processes Definition rEnsures that the same processes are used across multiple integrated product teams 3. Integrated process teams

1812. Processes Process teams and IPTs Level 2 Product Team 1 Level 2 Product Team 2 Level 2 Product Team 3 System Engineering Mechanical Engineering System Engineering Mechanical Engineering 3. Integrated process teams

1912. Processes Process team domain rMay span the whole project including all IPTs and their work teams rAlternately, may be more than one set of process teams 3. Integrated process teams

2012. Processes Process team types (1 of 4) rTypes Company -- All IPTs at one company have different processes than the IPTs at another company Location-- All IPTs at one location have different process teams than at another location Project -- Each IPT defines its own processes, and there is no independent set of process teams 3. Integrated process teams

2112. Processes Process team types (2 of 4) One process team for all Company 1 Company 2 Location 1 Location 2 Process team per company Process team per location

2212. Processes Process team types (3 of 4) rAdvantages of single teams Presents a uniform picture Allows functions such as CM to span whole project Simplifies communications among product teams 3. Integrated process teams

2312. Processes Process team types (4 of 4) rAdvantages of multiple teams Allows teams to use tools such as computers that they have been trained on Allows teams to use techniques learned on previous projects Promotes improvement of quality by seeing the same process applied over multiple projects 3. Integrated process teams

2412. Processes Process team reporting options Management Level 1 Product Team Process Teams Management Level 1 Product Team Process Teams Vs Independent Process Team Process Team Integrated with Product 3. Integrated process teams

2512. Processes 4. Processes rDefinition rPurpose of a process rTypes of processes r Problems 4. Processes

2612. Processes Definition rProcess - a particular method of doing something 4. Processes

2712. Processes Purpose of Process rBring the customer onto the project team Include customer in the process Give confidence that we know what we’re doing rCause harmony among stakeholders rImprove the use of tools & training rPromote reusability from project to project rImprove the way we do things 4. Processes

2812. Processes Types of processes (1 of 7) rDevelopment -- developing an item rAgreement -- agreeing on an item rChange -- changing an item rPhase -- completing a phase rConduct -- conducting an activity 4. Processes

2912. Processes Types of processes (2 of 7) Define stakeholders AgreeCaptureKick-offDevelop stakeholders item agreement document start Development process: Development involves defining stakeholders developing an item, agreement on and capture of the development, and then agreement to start using what was developed. The development process might be used to create a process, develop requirements, create a design, or make a change Development process: Development involves defining stakeholders developing an item, agreement on and capture of the development, and then agreement to start using what was developed. The development process might be used to create a process, develop requirements, create a design, or make a change 4. Processes

3012. Processes Types of processes (3 of 7) Agree among team 1 stakeholders Agree among team 2 stakeholders Agree between points of contacts local agreements Agreement process: Agreement among teams involves stakeholders working out details but then directing results through the point of contact for the team. This process is used in tasks such as document reviews, and development of interface Agreement process: Agreement among teams involves stakeholders working out details but then directing results through the point of contact for the team. This process is used in tasks such as document reviews, and development of interface team 1 consensus team 2 consensus agreement 4. Processes

3112. Processes Types of processes (4 of 7) 1. Open2. Assign 3. Hold4. Reject 5. Define stakeholders 7. Agree8. Capture9. Communicate10. Close 6. Solve identificationassignmentstakeholderssolution agreementdocumentationmessagesclosure holdrejection Change process: This process is used to modify an agreement. It might be used to update the configuration or to process action items Change process: This process is used to modify an agreement. It might be used to update the configuration or to process action items 4. Processes

3212. Processes Types of processes (5 of 7) Observe current state Observe desired state Generate correction Predict future desired state stimulus current desired correction future desired Example stimuli: periodic, degree of change, scheduled events Control process: This process is used to force the current state to the desired state. It might be used to control cost, schedule, and risk Control process: This process is used to force the current state to the desired state. It might be used to control cost, schedule, and risk 4. Processes

3312. Processes Types of processes (6 of 7) rPhase processes are outlined in discussion with the specific phase Design Acquire products Build Test Sell-off Phase processes: These processes are specific to the corresponding PBDA activities Phase processes: These processes are specific to the corresponding PBDA activities 4. Processes

3412. Processes Types of processes (7 of 7) rChecklists rCorresponds more closely to methods than to process rExample -- meetings Purpose Type (e.g. information, brain storming, consensus building) Agenda Time keeper and agenda enforcement Documentation and propagation of decisions Conduct processes: These are often checklists 4. Processes

3512. Processes Problems (1 of 5) Ignore Active use Process On the shelf 4. Processes

3612. Processes Problems (2 of 5) rBarriers to Process Acceptance Management doesn’t support a process People don’t know that a process has been started Process doesn’t match what people do Process steps cost more than the value they bring Process doesn’t have measurable steps There’s no incentive to execute the process 4. Processes

3712. Processes Problems (3 of 5) rMethods for overcoming barriers Obtain and publish management acceptance Include stakeholders in development of process Make each step clear, measurable, and useful Assign RAA for each step Hold kick-off meeting to start using the process Embed process in daily activities 4. Processes

3812. Processes Problems (4 of 5) rMethods for embedding process Incorporate process into the use of a tool Enforce process by committees Incorporate process steps into schedule 4. Processes

3912. Processes Problems (5 of 5) rExpense Process may become expensive Cost is easier to assess than benefit Benefit may be less than cost Examples Are there too many process steps Are the processes used or useful Are minutes to meetings worth the effort put into them 4. Processes

4012. Processes 5. Methods rDefinitions rExamples rHeuristics 5. Methods

4112. Processes Definitions rMethods are techniques for doing a process step 5. Methods

4212. Processes Examples rRequirements management rTPMs rRisk management rReviews 5. Methods

4312. Processes Heuristics (1 of 4) rHeuristic definition Rules of thumb rRule of thumb definition A rule based on practical experience without reference to scientific principals May have widespread validity, but may not always be true 5. Methods

4412. Processes Heuristics (2 of 4) rExample 1 -- People Good people are number one priority Better to have good people and bad process than good process and bad people rExample 2 -- Planning Plan the work and work the plan Develop requirements as if they were going to be implemented by another company Don’t confuse requirements and design 5. Methods

4512. Processes Heuristics (3 of 4) rExample 3 -- Hierarchy Don’t confuse requirements and levels of hierarchy RAA for a product should rest with only one IPT rExample 4 -- Order of tasks Parallel is good; serial is bad rExample 5 -- Partitioning Maximize cohesion and minimize coupling 5. Methods

4612. Processes Heuristics (4 of 4) rExample 6 -- Control Push control to the lowest level rExample 7 -- Optimization Work first; optimize last Simplify 5. Methods

4712. Processes 6. Intranet rFamiliarity rFlexibility rInput rNavigation rOutput rQuality 6. Intranet

4812. Processes Familiarity rFamiliar to engineers because the Intranet rMany hardware and software solutions available rA powerful & cost savings communications tool 6. Intranet

4912. Processes Flexibility rCan be used on simple & complex networks rAllows many tools including CM Quality checking Mail Scheduling Data management rAllows grouping data the way program is organized 6. Intranet

5012. Processes Input rIntranet Inputs Allows entering data in the format of the tool that generated the data Avoids converting from tool format to data base format More spontaneously adaptation than data base rData Base Inputs People use reports from data bases rather having to learn the data base Data base difficult to learn and slow in creating large reports 6. Intranet

5112. Processes Navigation rIntuitive big picture needing minimum training rGraphics and formatting rAccess from PCs, Sun workstations, and Macintoshes rSame look from different platforms rURLs point to information rHierarchical organization of page 6. Intranet

5212. Processes Output rDocument generation with HTML & hyperlinks rDesign documents as collection of files rIndependent authors rOffice tools support of HTML generation 6. Intranet

5312. Processes Quality (1 of 8) rRAA Each page should have an RAA owner Quality checking is important regardless of the tool used to maintain the library Poor quality irritates the users Poor quality leads to distrust of the information Quality checking should be frequent 6. Intranet

5412. Processes Quality (2 of 8) rOrganization Team Product Function Hybrid 6. Intranet

5512. Processes Quality (3 of 8) rTeam Separate home page for each team Each team places product and administrative information on home page Works well if teams organized in same way as products are organized A stable approach because teams assume ownership 6. Intranet

5612. Processes Quality (4 of 8) rProduct Separate home page for each product Owner assigned for each product Especially useful if teams aren’t organized in same way products are organized Easier to navigate for descriptions of product Takes more work to maintain than team organization 6. Intranet

5712. Processes Quality (5 of 8) rFunction Useful for information that doesn’t align on product or team boundaries Examples are common processes and procedures, reference documents, and phone numbers rHybrid A combination of all three methods plus others Intranet allows this flexibility 6. Intranet

5812. Processes Quality (6 of 8) rConsistent themes Helpful to a have a librarian with RAA for themes Navigation improved by seeing similar organization across teams and products Look and feel improved by consistent use of color, fonts, symbology, and graphics A difficult concept to enforce 6. Intranet

5912. Processes Quality (7 of 8) rCurrent links URLs point to files Links can be broken by several means File can be deleted Name of file can change Case of file name can change as a result of tool used to update the file Desirable to give any file being pointed to a fixed name and then not change it. Desirable that only one person have RAA for a file Tools exist to automatically report broken links 6. Intranet

6012. Processes Quality (8 of 8) rGarbage collection Keeping data current is often forgotten task Review based on the age of each file rPage Organization Primary means of navigation rSearch engines Powerful but require a lot of memory 6. Intranet