1. Introduction1 Agenda for introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Control q6. System engineering.

Slides:



Advertisements
Similar presentations
Facilitated by Joanne Fraser RiverSystems
Advertisements

1 PROJECT MANAGEMENT ROLE OF KEY PERSONNEL Bernd Madauss International Space University Strasbourg February, 2011
1 Homework r1. Module 2 r2. Module 4 r3. Module 7 r4. Module 8 r5. Module 9 r6. Module 11 r7. Module 12 r8. Module 14.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 3.1.
Alternate Software Development Methodologies
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Project Management.
Copyright 2002 Prentice-Hall, Inc. Chapter 3 Managing the Information Systems Project 3.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 3.1.
Stepan Potiyenko ISS Sr.SW Developer.
Managing the Information Technology Resource Jerry N. Luftman
Illinois Institute of Technology
Software Engineering For Beginners. General Information Lecturer, Patricia O’Byrne, office K115A. –
Computers: Tools for an Information Age
1 IS112 – Chapter 1 Notes Computer Organization and Programming Professor Catherine Dwyer Fall 2005.
CS Integration Management (Part 6) Bilgisayar Mühendisliği Bölümü – Bilkent Üniversitesi – Fall 2009 Dr.Çağatay ÜNDEĞER Instructor Bilkent University,
Defining the Activities. Documents  Goal Statement defines why helps manage expectations  Statement of Work what gets delivered defines scope  Software.
Miguel Nunes Information Systems Project Management IS Project Resources.
Copyright © 2003 by Prentice Hall Computers: Tools for an Information Age Chapter 14 Systems Analysis and Design: The Big Picture.
Effective Methods for Software and Systems Integration
Managing a Training Program Why train? Who will attend the training? What are the learning objectives? Strategies? Coverage? How will the training program.
Chapter 2: Overview of Essentials ISE 443 / ETM 543 Fall 2013.
Copyright 2002 Prentice-Hall, Inc. Managing the Information Systems Project 3.1 Chapter 3.
Copyright 2002 Prentice-Hall, Inc. Chapter 3 Managing the Information Systems Project Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Computer System Analysis
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Copyright © 2013 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Moving into Design SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Best Practices By Gabriel Rodriguez
1 Understanding Process Basics. BA 553: Business Process Management2 What is Systems Thinking? Systems thinking is a holistic approach to analysis that.
Software System Engineering: A tutorial
2 Systems Architecture, Fifth Edition Chapter Goals Describe the activities of information systems professionals Describe the technical knowledge of computer.
Administratively Controlled Information. Introduction and Background This is going to be hard – but also rewarding Survive beyond LEO Navigation Communication.
SCSC 311 Information Systems: hardware and software.
1 © The Delos Partnership 2004 Project Management Organisation and Structure.
Software Requirements Engineering: What, Why, Who, When, and How
Project Charters Module 3
1 Agenda for SE r1. System engineering r2. References.
University of Southern California Center for Systems and Software Engineering Barry Boehm, USC CS 510 Software Planning Guidelines.
ISO 9001 – an overview Tor Stålhane IDI / NTNU. ISO 9001 and software development ISO 9001 is a general standard – equally applicable to software development.
Copyright © 2013 Pearson Education, Inc. Publishing as Prentice Hall o P.I.I.M.T o American University of Leadership Ahmed Hanane, MBA, Eng, CMA, Partner.
1. Introduction1 Agenda for introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Product-based development.
1 Agenda for PBDA r1. Basic approach r2. Products r3. Cycles r4. Product-based development approach (PBDA)
1. PBDA1 Agenda for introduction q1. Course details q2. Disclaimer q3. Reasons why systems fail q4. Products q5. Cycles, phases, and activities q6. PBDA.
1. Introduction1 Agenda for Introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Control q6. System engineering.
10. Applications1 Applications Agenda (1 of 2) r1. Introduction r2. Example r3. Simple products r4. Classical development r5. Incremental builds r6. Spiral.
Information Systems System Analysis 421 Chapter 3 Managing the Information Systems Project.
第 11 組 MIS 報告. Phases of any information system ~ recognition of a business problem or opportunity ~ recognition of a business problem or opportunity.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Chapter 2 Managing the Information Systems Project 2.1.
1 Agenda for acquire-products activity r1. Objective r2. Level of products r3. Role of customer r4. Make or buy r5. Subcontractor selection r6. Acceptance.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Software Production ( ) Lecture 3: Dr. Samer Odeh Hanna (PhD) office: 318.
Collaborating for Quality Quality Assurance (QA) & Quality Control (QC) in the Accelerator Project (ACCSYS) Matthew Conlon ACCSYS QA/QC
8. Acquire products & build1 Agenda for acquire products activity r1. Objective r2. Level of products r3. Role of customer r4. Make or buy r5. Subcontractor.
1. PBDA1 Agenda for introduction q1. Course details q2. Disclaimer q3. Reasons why systems fail q4. Products q5. Cycles, phases, and activities q6. PBDA.
 Overview of Project management. ◦ Management. ◦ Project Management. ◦ Software Project Management. ◦ Project(Dimensions, Characteristics, Complexity,
Collaborating for Quality through the Project Quality Plan Matthew Conlon ESS ACCSYS QA/QC Quality Learning & Planning.
TOPIC : PROJECT MANAGER
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Chapter 1 Computer Technology: Your Need to Know
Software Configuration Management
Software and Systems Integration
Software Project Management
Enterprise Content Management Owners Representative Contract Approval
Chapter 3 Managing the Information Systems Project
CHAPTER 2 Testing Throughout the Software Life Cycle
Defining the Activities
ISCOM 361 PAPERS Education for Service--iscom361papers.com.
Project Management Process Groups
Presentation transcript:

1. Introduction1 Agenda for introduction q1. Course details q2. Basic approach q3. Products q4. Cycles, phases, and activities q5. Control q6. System engineering q7. Homework

1. Introduction2 1. Course details qCourse and instructor qCourse content qTextbook and time qSchedule qGrading qFormats 1. Course details

1. Introduction3 Course and instructor Course Systems Engineering Process Room Caruth Hall Instructor -- Jim Hinderer Work phone number -- (972) Home phone number -- (972) address Course details

1. Introduction4 Course content rShow how to develop a system from start to delivery rIllustrate a product-based development approach (PBDA) rShow applications to commercial and military systems, large and small systems, hardware and software systems, and people systems 1. Course details

1. Introduction5 Textbook and time rTextbook -- none rClass time -- 6:30 - 9:20 l 6:30 - 7:50 first lecture period l 7:50 - 8:00 break l 8:00 - 9:20 second lecture period 1. Course details

1. Introduction6 Schedule r8/28 Introduction r9/4Labor Day, no class r9/11, 18Understanding-customer r9/25, 10/2, 9, 16Design q10/23Acquisition and build r10/30Verification and sell-off r11/6, 13Management r11/20Processes r11/27Report, no class r12/4Implementation r12/11Final, take home 1. Course details

1. Introduction7 Grading qHomework 30% qExam30% qFinal 40% 1. Course details

1. Introduction8 Formats qNon-electronic: Pencil and paper qElectronic: Office 97 Word, Excel, PowerPoint qPC and not Macintosh 1. Course details

1. Introduction9 2. Basic approach qSystem engineering qGuidelines qActivities qApplication 2. Basic approach

1. Introduction10 System engineering qSystem engineering is more of an art than a science. qAlmost any method of system engineering will work if someone takes ownership of success qNo one method of system engineering is better than all the others qThe goal of this course is to explain one method for developing systems and to indicate how this method relates to other methods. 2. Basic approach

1. Introduction11 Guidelines qWisdom qSimplicity 2. Basic approach

1. Introduction12 Activities Determine what customer wants Decide what to do Get what it takes to do it Do it Check it out Convince customer it’s what he or she wanted Make it happen 2. Basic approach

1. Introduction13 Application qApply same set of activities to each product 2. Basic approach

1. Introduction14 3. Products qProduct definition qProducts composed of products qNeed for lower-level products qExamples 3. Products

1. Introduction15 Product definition (1 of 2) qA product is something produced by nature or by human industry or art qA product is something we can procure -- hardware, software, data, services. 3. Products

1. Introduction16 Product definition (2 of 2) qExamples l Hardware -- space shuttle, house, circuit card, resistor l Software -- program, firmware l Data -- documents, management objects l Services -- activities qThe concept of a product makes explaining system engineering easier. 3. Products

1. Introduction17 Products composed of products Level 1 Product Level 2 Product 1 Level 2 Product 2 Level 3 Product 1 Level 3 Product 2 Level 4 Product 2 Higher-level products Lower-level products Level 4 Product 1 Level 4 Product 3 3. Products

1. Introduction18 Need for lower-level products qA product that doesn’t need development or support does not need lower-level products qWhether a product needs lower-level products depends upon whether we care about it. l A stone has no lower level components l A light bulb has lower level components, but purchasers don’t care l A personal computer has lower level components, and some people may care qWhether we want to put effort into it 3. Products

1. Introduction19 Example 1 -- model airplane Model airplane FuselageWingStabilizerRudderGlue Good example -- We can use the lower-level products to make the higher-level product 3. Products

1. Introduction20 House KitchenBathroomBedroom 1Bedroom 2Garage Bad example -- We wouldn’t use the lower-level products to make the higher-level product Example 2 -- house, bad example 3. Products

1. Introduction21 Example 3 -- house, good example House Plumbing FramingRoofElectrical Good example -- We can use the lower-level products to make the higher-level product FoundationDry wall 3. Products

1. Introduction22 4. Cycles, phases, and activities qDefinitions qProduct life cycle qPre-develop-phase activities qDevelop-phase activities qPost-develop-phase activities qNotes on activities qExample 4. Cycles, phases, and activities

1. Introduction23 Definitions qCycle -- a complete set of events occurring in the same sequence l Product life cycle l Contract life cycle qPhase -- part of a cycle; the period of time the activities take qActivity -- execution of a set of tasks qProcess -- steps used to accomplish an activity 4. Cycles, phases, and activities

1. Introduction24 Product life cycle Phases Time Pre-develop Post-develop Develop 4. Cycles, phases, and activities

1. Introduction25 Pre-develop-phase activities Sub phases Time Meet the customer Discuss the work Respond to RFP Sub phases overlap Identify opportunity 4. Cycles, phases, and activities

1. Introduction26 Develop-phase activities (1 of 2) Determine what customer wants Decide what to do Get what it takes to do it Do it Check it out Convince customer it’s what he or she wanted Make it happen Manage Understand requirements Design Acquire products Build Verify Sell-off 4. Cycles, phases, and activities

1. Introduction27 Develop-phase activities (2 of 2) Sub-phases Time Understand requirements Design Acquire products Build Verify Sell off Sub-phases overlap Manage 4. Cycles, phases, and activities

1. Introduction28 Post-develop-phase activities Sub-phases Time Train Produce Upgrade Maintain Operate Dispose Sub-phases overlap Field test and validate Support 4. Cycles, phases, and activities

1. Introduction29 Notes on activities qNot every product has the same activities l Developing software may not require acquiring products l Integration or verification may be deferred to another level qSome products may be so simple that they don’t require formal management. 4. Cycles, phases, and activities

1. Introduction30 Example 1-- build a house Activities Time Learn what buyer wants Have architect make blueprint Get land and lumber Build See if the house is OK Close Supervise 4. Cycles, phases, and activities

1. Introduction31 5. Control qControl by engineering products qControl by product-based development approach (PBDA) 5. Control

1. Introduction32 Control by engineering products (1 of 2) Level N Product Deliverable Products Environment Products Engineering Products Products can be divided into three delivered products. Environment products, and engineering products. Products can be divided into three delivered products. Environment products, and engineering products. 5. Control

1. Introduction33 qDeliverable products -- part of level-N product q Environment products -- physical products that interact physically with the level-N product throughout its life, such as manufacturing, test, and maintenance equipment q Engineering products -- other products that enable development of the level-N product, such as specifications Control by engineering products (2 of 2) Engineering products support the development of delivered products and environment products Engineering products support the development of delivered products and environment products 5. Control

1. Introduction34 Control by PBDA (1 of 15) External: higher product teams External: lower product teams 2. Understand req 3. Design 4. Acquire 1. Manage 5. Build 6. Verify 7. Sell off specs, I/Fs lower specs & I/Fs lower contracts, specs, interfaces lower test results contracts contracts, specs, interfaces agree design schedule, budget, risks, TPPs, issues, AIs, plans, timeline, changes, problems, legal agree control, status build proc test proc FCA TRRVR PDRCDR RR MR CR lower product, test results, test spec lower products PCA status people, facilities, tools, capital, communications, library product test results test spec

1. Introduction35 Control by PBDA (2 of 15) Higher Product Lower Product 1 Lower Product 2 Lower Product N Product of Interest PBDA is applied to each product separately 5. Control

1. Introduction36 Example with 10 products System Subsystem HWCI Unit CSCI HWCIUnit CSCI Control by PBDA (3 of 15) 5. Control

1. Introduction37 Developing the example with 10 instantiations of PBDA Control by PBDA (4 of 15) 5. Control

1. Introduction38 Control by PBDA (5 of 15) rEnvironment (6) -- people, facilities, tools, capital, communications, library rControl (11) -- schedule, budget, risks, TPPs, issues, AIs, timeline, plans, changes, problems, legal rReviews and audits (9) --MR, RR, CD, PDR, CDR, TRR, VR, PCA, FCA 26 management activities for each product in PBDA 5. Control

1. Introduction39 Control by PBDA (6 of 15) rUnderstand (0) -- rDesign (3) -- design, lower specs, lower interfaces rAcquire (1) -- lower contracts rBuild (2) -- build procedure, product rVerify (3) -- test spec, test procedure, test results rSell off (1) -- agreement 10 management activities for each product in PBDA 5. Control

1. Introduction40 Control by PBDA (7 of 15) rHigher inputs (3) -- contracts, specs, interfaces rLower inputs (4) -- lower product, lower test results, lower test spec, status Inputs are monitored by aren’t MOs

1. Introduction41 Control by PBDA (8 of 15) qSome management objects can be shared between levels qNot all management objects are needed at each level. Not all management objects must always be used 5. Control

1. Introduction42 Control by PBDA (9 of 15) qSystem engineering has evolved slowly qMany disciplines such as software and electrical engineering could not identify where they fit within system engineering, so they defined what they needed independently qAs a result, there are many overlapping concepts qOther disciplines fit in as developers of products using PBDA PBDA helps understand where other disciplines fit 5. Control

1. Introduction43 Control by PBDA (10 of 15) qMakes explaining system engineering easier qAllows these disciplines to be parallel rather than randomly aligned system engineering software supportabilityelectrical engineering maintainability configuration management PBDA allows disciplines to use similar approaches 5. Control

1. Introduction44 Control by PBDA (11 of 15) qAlternate approach l 106 activities l 966 management objects l Result of many overlapping perspectives Alternate approaches have a lot of activities to manage 5. Control

1. Introduction45 Control by PBDA (12 of 15) qPBDA l 7 activities l 43 items to manage 36 management objects 7 inputs total of N for a product with N lower products l Result of applying same approach at all levels PBDA is simpler 5. Control

1. Introduction46 Control by PBDA (13 of 15) complexity requirementssize hostility use no MOs use all MOs When to use PBDA is determined by several factors 5. Control

1. Introduction47 Control by PBDA (14 of 15) q-1 -- maintained but an obstacle q 0 -- not maintained q 1 -- maintained but not used q 2 -- maintained and used to monitor q 3 -- maintained and used to control q 4 -- maintained and used to optimize Value of management object can be positive or negative 5. Control

1. Introduction48 Control by PBDA (15 of 15) An example pareto of management objects by likely use 5. Control decreasing likelihood of use product (1) lower products (1) higher inputs (3) budget & schedule (2) environment (6) design (3) build (1) problems and changes (2) risks & TPPs (2) verify (3) plan and timeline (2) lower inputs (3) reviews and audits (9) agreement (1) acquire (1) issues and AIs (2) legal (1) physical paper external paper

1. Introduction49 6. System engineering qDefinition of RAA qDefinition of a system qDefinition of a product engineer qDefinition of a project manager qDefinition of a system engineer 6. System engineering

1. Introduction50 Definition of RAA (1 of 2) qR -- Responsibility: Who is supposed to do the task qA -- Authority : Who has the authority to do the task qA -- Accountability : Who gets blamed if something goes wrong RAA has three parts 6. System engineering

1. Introduction51 Definition of RAA (2 of 2) qThe goal is to l Give authority to people who are responsible and accountable l Make people with authority responsible and accountable The goal of RAA is to assign duty and power to get the job done The goal of RAA is to assign duty and power to get the job done 6. System engineering

1. Introduction52 Definition of a system qDefinition used here l Each product is a system qDefinitions used by others l System is the highest level product l System is the highest level product within a company or an enterprise Each product is a system 6. System engineering

1. Introduction53 Definition of a product engineer qThe person who has RAA for the product qPerforms the roles of the project manager and the system engineer The product engineer has RAA for the product 6. System engineering

1. Introduction54 Definition of a project manager qThe person who has RAA for the product qManages project qProvides the environment to develop the product qGenerally has a significant level of technical depth The project manager is a product engineer who concentrates on management The project manager is a product engineer who concentrates on management 6. System engineering

1. Introduction55 Definition of a system engineer (1 of 6) qDefinition used here l The person who has RAA for the technical part of the product and the administrative duties associated with the technical part l Reports to project manager As used here, system engineering does a subset of the product engineer tasks As used here, system engineering does a subset of the product engineer tasks 6. System engineering

1. Introduction56 Definition of a system engineer (2 of 6) qDefinitions used by others l Customer advocate and system auditor l Technical leader l Developer of the system front end l Requirements keeper There are many other definitions of system engineer used in practice There are many other definitions of system engineer used in practice 6. System engineering

1. Introduction57 Definition of a system engineer (3 of 6) qPerceptions of system engineer vary from technical leader to clerk qProblems l Not technical l Role not understood by management l Doesn’t get done in time l Overcome by events The perception of the system engineering job varies from technical leader to clerk The perception of the system engineering job varies from technical leader to clerk 6. System engineering

1. Introduction58 Definition of a system engineer (4 of 6) qSystem engineer should lead the parade rather than clean up behind it qA problem the system engineer must overcome is being passed by the design, product acquisition, build, and verification activities The ideal system engineer is a leader 6. System engineering

1. Introduction59 Definition of a system engineer (5 of 6) qLeadership involves finding the leaders and being a leader among the leaders qLeadership involves finding the most active part of a project and leading at that point qA system engineer can become absorbed in processes to the point of abdicating leadership Becoming a leader takes a lot of work and there are many pitfalls Becoming a leader takes a lot of work and there are many pitfalls 6. System engineering

1. Introduction60 Definition of a system engineer (6 of 6) modifiersynthesizer challenger reproducer dreamer innovator planner practicalizer risk creativity A challenge is be recognized as an innovator 6. System engineering

1. Introduction61 7. Homework (1 of 2) q1. What is the best method for developing products: (a) product-based-development approach (PBDA), (b) object-oriented development, (c) clean room, (d) no one method of system engineering is better than all the others? q2. How many products are shown in example 1.3-3: (a) 0, (b) 1, (c) 6, (7)? q3. How many design activities are associated with the products in example 1.3-3: (a) 0, (b) 1, (c) 6, (7)? 7. Homework

1. Introduction62 Homework (2 of 2) q4. The activity of getting land and lumber in example is which one of the following PBDA activities: (a) manage, (b) design, (c) acquire products, (d) build? q5. An interface document between subsystems is an example of (a) development product, (b) engineering product, (c) environment product, (d) activity? q6. Which of the following has the greatest RAA: (a) product engineer, (b) system engineer, (c) project manager, (d) all have the same RAA? 7. Homework