1. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M04 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project Module 04 System Engineering Lifecycles

2. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 2 Goal of This Module  To look at the process from the perspective of the system analyst or system engineer - the “technical coordinator” of the project  To examine how software must fit into the process for developing all of the technical parts of a product

3. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 3 The System Engineering Lifecycle is...... the highest level “technical” lifecycle for a product or system being built It incorporates many disciplines It begins with system concept and ends with system integration Software engineering success is largely dependent on successful execution of this lifecycle

4. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 4 Typical System Architecture Subsystem (segment) Subsystem (segment) Subsystem (segment) Product or Item (configuration item) Product or Item (configuration item) Product or Item (configuration item) System Subsystem (segment)

5. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 5 Example DisplayPrinterKeyboard Processor and Memory System Software Power Supply Computer System Unit

6. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 6 The System Engineering (or System Analysis) Lifecycle Integrate & Test Design the Architecture & Allocate Requirements to Parts Build the System Analyze Requirements First two steps are repeated for each level in the system architecture Final step is repeated for each level This step occurs separately for each configuration item

7. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 7 A Typical Sequence for a Large System

8. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M04 - Version 8.01 Reviewing the Steps of the System Engineering Lifecycle

9. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 9 Step 1 - Analyze the Requirements of the System  Determine what the customer really wants  Produce testable specifications (may be in the form of simulations of expected behavior, use cases, specification documents, system requirements models, or other things) … continued

10. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 10 Analyze the Requirements of the System (continued)  Confirm specifications with customer  Will later use the specifications to test and evaluate the system, after it is built Note for U.S. Government Contracts: In a DoD program, this activity occurs (theoretically) during the concept exploration phase

11. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 11 Software Notes  Software can be used to support these activities –Simulations –Requirements Models –Data Analysis  The software needs for the final system are not yet identified  However, there is often a need to evaluate potential algorithms for performance and effectiveness

12. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 12 Step 2 - Design the System  Select/Design the architecture of the system << Synthesis, not analysis –System engineer and/or chief architect –Software engineering expertise must be included in the process  Determine the major parts (functional decomposition into sub-systems)  Determine the interfaces between the subsystems … continued

13. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 13 Design the System (continued)  Allocate requirements to the parts  (will later repeat at next level of detail) Note: larger systems require more repetitions, because there tend to be more levels

14. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 14 Example of Requirements Allocation Requirements: - Sense Status - A/D conversion - Display Sensor Analog Device A/D Converter Software

15. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 15 How Many Levels of Detail? You stop repeating when you have reached enough detail to define the configuration items -- the lowest level parts that you want to manage at the system level –How do you want to break the system into parts? –How do you want to manage the project? –What are the most sensible logical divisions?

16. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 16 Configuration Items …  A hardware device might be a configuration item –Examples: a chassis or a circuit board  A software configuration item is sometimes called a software item (SI) –Examples: a compiler, a word processor, a data base system, a transaction system

17. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 17 Software Note  With object oriented design concepts, selection of configuration items becomes an even more difficult task than it used to be –and it has often been a difficult task

18. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 18 Where Will Software Be Used in the System?  This is the question that the software system engineer must answer during the system design phase  Microcode, firmware, etc. are really software, but perhaps requiring different processes and design cycles

19. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 19 Where Will Software be Used? (continued)  What to put in software and where software is used in a system are very important system design issues  It is common to underscope the amount of software, especially if no software people are involved with the system design

20. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 20 More Software Notes  A typical large system may have MANY software configuration items  Some designers may combine hardware and software into a configuration item  After identification of the software functions, selection of configuration items is the next key decision that software managers and technical staff must participate in deciding

21. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 21 Possible Exam Question  Give two reasons why software expertise is vital to good system design, even if the system is mostly hardware  1) To identify all of the software and all of the places where software is the best choice to implement the requirements  2) To help select the right software configuration items

22. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 22 Selection of Software Items (Configuration Items)  Ideally, a software item is something that will be: –Developed independently –Tested independently (cases, procedures, etc.) –Sold separately (part number, upgrades, price, etc.) –Maintained as a separate unit –Supported with its own set of documentation

23. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 23 Selection of Software Items (continued)  A software item may also –Have a separate target processor –Or a separate programming language  Sometimes it is something that is so important to system functionality that it is separated out just to keep closer management visibility

24. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 24 Considerations when Selecting Software Items (SIs)  How many contractors will build / manage the SI? –Ideally, one contractor per SI  How many target processors? –Should there be one per SI?  How many programming languages? –Ideally, one per SI … continued

25. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 25 Considerations when Selecting Software Items (continued)  What are the schedules / delivery dates? –Several releases of an SI vs. multiple Sis  What is the best maintenance approach? –Can you change one part without re-compiling and re-testing many unrelated parts?  How big will it be? –If it is too big, perhaps it should be broken up  Interfaces to other products? –Keep them simple

26. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 26 Step 3 - Build the System  “Subcontract” the software, electrical, mechanical, or other development tasks to software engineers, electrical engineers, etc.  Manage and maintain communication and coordination during this period –Example: controlling change to requirements and interfaces –Example: resolving differences of opinion about interpretation of specifications

27. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 27 Step 4 - Integrate the System  Put the parts together  This is the real test of whether the System Engineer did the job right This part is sometimes ignored or downplayed by practicing system engineers

28. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 28 Subcontracting the “Build the System” Process Integrate & Test Design the Architecture & Allocate Requirements to Parts Build the System Analyze Requirements PackagingSoftwareElectronics Software Development Lifecycle

29. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M04 - Version 8.01 How to Make Sure the Software Fits the System

30. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 30 Four Items Constitute a Good Starting Point for a SW Project  If you have these four, make sure they are as complete and correct as you can get them  If you do not have them, make them and then confer with the customer(s) to see if they agree with what they say  If equivalent information is available elsewhere, make sure you have copies of the equivalent information AND strong communication with whomever is in charge of changing things

31. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 31 Four Key Items - The Starting Point for Successful Software 1) Software Statement of Work -- what to do and what to deliver -- often the basis for a contract 2) Software Requirements Specification -- specifically, what the software is required to do and how you will test to see if it is correct … continued

32. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 32 Four Key Items -... (continued) 3) System Design Description -- the parts of the system, how they interface, how requirements are allocated 4) Requirements Trace -- from software to system to customer and back

33. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 33 Illustration Produce a Product (Software Process) System Specs Characterize the Product What to Do Requirements Trace Allocation, Products INPUT PRODUCT Software Rqmts What to Produce Statement of Work

34. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 34 Some Important Considerations  Make sure you include the views of all “customers” relative to the four items in the starting point  Make sure you establish who controls changes to each requirement, specification, statement of work, etc. –And make sure they are motivated to inform software staff of changes  Understand key dependencies on other parts of the system

35. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 35 Software Statement of Work  Should clearly state all of the entry criteria for the software effort  Plus the specific tasks to be performed and deliverables to be produced  Constraints on schedule, resources, etc. (where possible -- sometimes it is your job to determine the needed schedule and resources)  Plus applicable standards, etc

36. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 36 Word to the Wise If nobody provides a software statement of work, the software manager may need to extract one from a system statement of work -- or write their own

37. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 37 Types of Software There are many kinds of software, and each of them may require a different lifecycle model, a different process, different kinds of specifications, and different levels of support Good software planning begins with an analysis of ALL the software to be built

38. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 38 Types of Software: Demonstration or Requirements Prototype  Intended to demonstrate a concept and then be thrown away.  Goal is to get something working quickly and see what it looks like.  Usually found in early phases of system lifecycle  Generally less emphasis on testing and quality assurance

39. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 39 Types of Software: Evolutionary Prototype  Intended to try a concept and then improve on it until it is acceptable (but then throw away or use?)  Usually found in early phases of system lifecycle  But sometimes this is the paradigm for developing production software  In which case more formality and focus on testing and quality

40. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 40 Types of Software: Production Software  Intended to be robust, easily maintained, error free, reliable, etc. Generally the most expensive and slowest to develop  Generally found only in later phases of system life cycle  Beware of attempts to use prototypes as production software

41. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 41 Types of Software: Test Software  Intended to test some other software or hardware. May be of “throwaway” or of “production” quality  Found in all phases of system lifecycle

42. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 42 Types of Software: Simulation Software  Intended to simulate some other system or environment as part of a design or testing effort.  Used throughout the system development lifecycle  Important to keep changes under control so that what you test with corresponds to what you designed with

43. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 43 The Problem of Controlling Simulation Software  If you do not control simulation software, you may test the real system against something incompatible with what you used to define it Test Real System Simulate Environment System Development Time Passes

44. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 44 Types of Software: Software Development Tools  Intended to build other software  Found in all phases of the system lifecycle  Tendency to be sloppy in development if you are developing your own tools –“I will fix it if it has a problem” –But what about those who come after you?

45. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 45 Types of Software: Debugging Software  Used to find and fix errors in other software  Used in all phases  Needs to be robust but not usually safety or time critical  Good program planning includes up- front planning of testing and debugging tools

46. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 46 Types of Software: Installation Software  Intended to support installation of a system  Generally developed late in system life cycle  Often not designed carefully as part of the overall system  But may be crucial for success, especially if the customer does the installation!

47. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 47 Types of Software: Test Support Software  Intended to support various forms of system testing  Generally developed late in system life cycle  Generally viewed as temporary so not usually developed with the same care as application software  Sometimes automatically generated via test generation tools

48. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 48 Types of Software: Support Software  Intended to support operation or maintenance of a system  Generally developed late in system life cycle  Often not designed carefully as part of the overall system  But may be used for a long time

49. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 49 What Types of Software Apply to My Project?  This is a key question that must be determined by the system engineering and software engineering staff  Each type may require its own analysis of lifecycle and process requirements

50. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 50 Deciding What Types of Software Apply to Your Project  Be careful to team the system engineering function with the software engineering function to achieve the most appropriate allocation of system requirements to various software types

51. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 51 Summary of Module  The system engineering lifecycle incorporates many disciplines  One must determine what functions will be implemented in software and what other roles software will play  Selection of software items is a key step in the process, along with allocation of requirements to each... continued

52. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 52 Summary of Module (continued)  Four key items set the stage for successful software  The types of software used on the project must be identified

53. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 53 END OF MODULE 04

54. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M04 - Version 8.01 Appendix Issues regarding U.S. Government Projects (for those doing US government contracts)

55. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 55 DoD Note  The system design step occurs (in theory) during the Demonstration/Validation phase of a DoD procurement  However, due to the need to “see something that works”, there is often too much emphasis on building prototype hardware and not enough on building good specifications  Software suffers from this because software quality depends on having good specifications -- more so than hardware because of its intangible nature

56. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M04 - Version 8.01 56 DoD Note 1) Software Statement of Work - often just a system SOW unless you are doing a software- only contract 2) Software Requirements Specification - in theory this is developed during final steps of Demonstration/Validation phase, based on flowdown of system requirements (PIDS/SSS) –In practice, you may need to do it yourself and beg the customer and system engineer to sign off 3) System Design - contained in SSS, CIDS and SSDD –In practice, system engineers resist doing an SSDD 4) Requirements Trace - in SSDD if you have one