Software Engineering Strengths And Weaknesses In
October 2010Software Engineering Strengths andWeaknesses in Systems EngineersDr. Paul Shebalin, DirectorThe Wayne E. Meyer Institute, Naval Postgraduate Schoolpshebali@nps.edu, 831-656-1047“Applied and Basic Research in SystemsAnalysis, Modeling and Engineering
Topics SE at the Naval Postgraduate School SE4003 Systems Software Engineering The Need for Systems Engineers to Serve asSoftware Engineers Software Engineering Capability Evaluation Observations RecommendationsOctober 2010 v42
Mission of the Naval Postgraduate School NPS provides high-quality,relevant and uniqueadvanced education andresearch programs thatincrease the combateffectiveness of the NavalServices, other ArmedForces of the U.S. and ourpartners, to enhance ournational security.October 2010 v43
NPS Summary A Department of the Navy graduate school foundedin 1909 located in Monterey, California Four schools and 65 Curricula in engineering,science, business, public policy, operations research,information sciences, international studies, nationalsecurity studies and homeland security. Four research institutes and 20 centers Faculty: 248 Tenure-Track, 429 Non-TT Graduate Students: 1500 Resident, 750 Non-Resident– 44% Navy, 12% USMC, 23% other US Services, 14%International, 7% CivilianOctober 2010 v44
NPS Systems Engineering ProgramsSE Certificate282DL and SEM (PD21)721DL4 quarters8 quarters(with embeddedrefresher)8 quarters8 quarters(with refresher)8 quarters4 courses32 courses16 courses36 courses16 coursesIntegrated Project(in courses)ProjectProjectThesisThesis2 cohorts/year1 cohorts/year12 cohorts/year1 cohort/year*1 cohort/year30 per cohort20 per cohort 30 per cohort18 per cohort20-25 per cohort23 students34 students314 students43 onboard41 studentsOctober 2010 v4AS of 9/9/105
MSSE Core Courses Resident and non-residentprograms share a commonnine course core curriculum Informed by INCOSE andDOD reference curricula DAU Equivalencies Burnt orange coursescompose the certificate Degree requirements met bycore, 4 course track, and 3course project P-codes can imposeadditional requirementsOctober 2010 v4Fundamentals of Systems EngineeringSystems SuitabilitySystems AssessmentFundamentals of Engineering ProjectManagementEngineering Economics and CostEstimationCapability EngineeringSystem Architecture and DesignSystems Software EngineeringSystems Integration and Development6
SE4003 Systems Software Engineering Course objective: teach students the basic concepts of softwareengineering and methods for requirements, definition, designand testing of software. Course framework:– 10-week quarter– Prerequisite: Computer Programming Course– Text by Pressman: Software Engineering: A Practitioner’s Approach(7th Ed.) (Chapters 1-10, 17-19)– Assigned readings and class presentations, exercises and discussionscomplement hands-on project experience.– Embedded System Software Project: Team of 3-5 members Software development for Lego NXT robot using NXC (Not eXactly C) orJava Deliverable and non-deliverable software products Basis for identifying SWE strengths and weaknessesOctober 2010 v47
ROCS System HierarchyRapid ObstacleClearance System(ROCS)RoboticAutonomousVehicle (RAV)SegmentPersonnelSegmentARAV Chassis andDrive salSegmentBCRAV ComputerControllerSubsystemMaintenanceSegmentDRPU ComputerSubsystemEOctober 2010 v4ROCSProgramming Unit(RPU)SegmentRPU quipmentComponentOperating SystemSoftwareComponentRAV OperationalControl SoftwareComponentRPU OperatingSystemComponentROCS SoftwareDevelopmentEnvironmentComponent8
Hands-On Project HardwareRobotic Autonomous Vehicle (RAV)PrototypeLEGO NXT UltrasonicSensorTwo (2) LEGO NXTServo MotorsLEGO NXT BrickLEGO NXT LightSensorOctober 2010 v4LEGO NXT LightSensor9
Systems Engineers as Software Engineers? Why do systems engineers need softwareengineering knowledge, skills, and abilities?– To be better systems engineers?– To be better software engineers? Many systems engineers will be called to serveas software engineers on a software project –development, maintenance, V&V, T&E, How software-engineering-capable are thesystems engineers we’re graduating? How can we measure SWE capability?October 2010 v410
Measuring SWE Capability Formal testingPeer evaluationProcess qualityProduct qualityTimeliness and appropriatenessRepeatability and long-term performanceObservation and evaluationOctober 2010 v411
Observation and Evaluation Method Define evaluation criteria using– “Knowledge, Skills, and Abilities” (KSAs)– SWEBOK (IEEE) breakdown of SWE topics Consider the results of five offerings ofSE4003 with 82 students and 27 project teams Subjectively, evaluate the student performancethrough the use of a Pugh Matrix– -1, 0, 1 representing Worse, Same, Better ofaverage student performance compared with thatexpected of a competent software engineerOctober 2010 v412
KSA’s Skills Abilities– Effectiveness in usingtools and technology– E.g., effectiveness inusing a specific softwaredevelopmentenvironment (SDE)– The wherewithal toperform specific tasks– E.g., the ability to createa suitable SoftwareRequirements AnalysisDocument Knowledge– Mental data representinginformation, facts,relationships, concepts,logical implications, etc.– E.g., object-orientedsoftware engineeringconceptsOctober 2010 v413
SWEBOK Topics BreakdownA.B.C.D.E.F.G.H.I.J.AreaSubareasSW Requirements7Software Design6Software Construction3Software Testing5Software Maintenance4SW Configuration Mgt6SW Engineering Mgt6SW Engineering Process4SWE Tools and Methods2Software Quality3October 2010 v4Topics28251316151724161411Subtopics131591414
A. Software Requirements1. Software requirements fundamentalsa. Definition of software requirementb. Product and process requirementsc. Functional and non-functionalrequirementsd. Emergent propertiese. Quantifiable requirementsf. System requirements and softwarerequirements2. Requirements processa.b.c.d.Process modelsProcess actorsProcess support and managementProcess quality and improvement3. Requirements elicitationa. Requirements sourcesb. Elicitation techniquesOctober 2010 v44. Requirements analysisa. Requirements classificationb. Conceptual modelingc. Architectural design and requirementsallocationd. Requirements negotiation5. Requirements specificationa. System definition documentb. System requirements specificationc. Software requirements specification6. Requirements validationa.b.c.d.Requirements reviewsPrototypingModel validationAcceptance tests7. Practical considerationsa. Iterative nature of requirementsprocessb. Change managementc. Requirements attributesd. Requirements tracinge. Measuring Requirements15
B. Software Design1. Software design fundamentalsa.b.c.d.General design conceptsContext of software designSoftware design processEnabling techniques2. Key issues in software designa.b.c.d.ConcurrencyControl and handling of eventsDistribution of componentsError and exception handling and faulttolerancee. Interaction and presentationf. Data persistence3. Software structure and architecturea. Architectural structures andviewpointsb. Architectural styles(macroarchitectural patterns)c. Design patterns (microarchitecturalpatterns)d. Families of programs and frameworksOctober 2010 v44. Software design quality analysis andevaluationa. Quality attributesb. Quality analysis and evaluationtechniquesc. Measures5. Software design notationsa. Structural descriptions (static)b. Behavioral descriptions (dynamic)6. Software design strategies and methodsa.b.c.d.e.f.General strategiesFunction-oriented (structured) designObject-oriented designData-structure centered designComponent-based design (CBD)Other methods16
C. Software Construction1. Software construction fundamentalsa.b.c.d.Minimizing complexityAnticipating changeConstruction for verificationStandards in construction2. Managing constructiona. Construction methodsb. Construction planningc. Construction measurement3. Practical considerationsa.b.c.d.e.f.October 2010 v4Construction designConstruction languagesCodingConstruction testingConstruction qualityIntegration17
D. Software Testing1. Software testing fundamentalsa. Testing-related terminologyb. Key issuesc. Relationships of testing to other activities2. Test levelsa. The target of the testsb. Objectives of testing3. Test techniquesa.b.c.d.e.f.g.Based on tester’s intuition and Usage-basedBased on nature of applicationSelecting and combining techniques4. Test-related measuresa. Evaluation of the program under testb. Evaluation of the tests performed5. Test processa. Management concernsb. Test activitiesOctober 2010 v418
Process SummarySWEBOK TopicsKSA FrameworkEvaluationSoftware EngineeringStrengths and WeaknessesObservationsWhen assigned a software engineering role:What level of software engineering knowledge would thesystems engineer have with regard to a SWEBOK topic?What level of software engineering ability would the systemsengineer have with regard to a SWEBOK topic?October 2010 v419
A. Software Requirements: Knowledge1. Software requirements fundamentalsa. Definition of software requirementb. Product and process requirementsc. Functional and non-functionalrequirementsd. Emergent propertiese. Quantifiable requirementsf. System requirements and softwarerequirements2. Requirements processa.b.c.d.Process modelsProcess actorsProcess support and managementProcess quality and improvement3. Requirements elicitationa. Requirements sourcesb. Elicitation techniquesStrengthWeaknessOctober 2010 v44. Requirements analysisa. Requirements classificationb. Conceptual modelingc. Architectural design and requirementsallocationd. Requirements negotiation5. Requirements specificationa. System definition documentb. System requirements specificationc. Software requirements specification6. Requirements validationa.b.c.d.Requirements reviewsPrototypingModel validationAcceptance tests7. Practical considerationsa. Iterative nature of requirementsprocessb. Change managementc. Requirements attributesd. Requirements tracinge. Measuring Requirements20
A. Software Requirements: Ability1. Software requirements fundamentalsa. Definition of software requirementb. Product and process requirementsc. Functional and non-functionalrequirementsd. Emergent propertiese. Quantifiable requirementsf. System requirements and softwarerequirements2. Requirements processa.b.c.d.Process modelsProcess actorsProcess support and managementProcess quality and improvement3. Requirements elicitationa. Requirements sourcesb. Elicitation techniquesStrengthWeaknessOctober 2010 v44. Requirements analysisa. Requirements classificationb. Conceptual modelingc. Architectural design and requirementsallocationd. Requirements negotiation5. Requirements specificationa. System definition documentb. System requirements specificationc. Software requirements specification6. Requirements validationa.b.c.d.Requirements reviewsPrototypingModel validationAcceptance tests7. Practical considerationsa. Iterative nature of requirementsprocessb. Change managementc. Requirements attributesd. Requirements tracinge. Measuring Requirements21
B. Software Design: Knowledge1. Software design fundamentalsa.b.c.d.4. Software design quality analysis andevaluationGeneral design conceptsContext of software designSoftware design processEnabling techniquesa. Quality attributesb. Quality analysis and evaluationtechniquesc. Measures2. Key issues in software designa.b.c.d.ConcurrencyControl and handling of eventsDistribution of componentsError and exception handling and faulttolerancee. Interaction and presentationf. Data persistence5. Software design notationsa. Structural descriptions (static)b. Behavioral descriptions (dynamic)6. Software design strategies and methods3. Software structure and architecturea. Architectural structures andviewpointsb. Architectural styles(macroarchitectural patterns)c. Design patterns (microarchitecturalpatterns)d. Families of programs and frameworksOctober 2010 v4StrengthWeaknessa.b.c.d.e.f.General strategiesFunction-oriented (structured) designObject-oriented designData-structure centered designComponent-based design (CBD)Other methods22
B. Software Design: Ability1. Software design fundamentalsa.b.c.d.4. Software design quality analysis andevaluationGeneral design conceptsContext of software designSoftware design processEnabling techniquesa. Quality attributesb. Quality analysis and evaluationtechniquesc. Measures2. Key issues in software designa.b.c.d.ConcurrencyControl and handling of eventsDistribution of componentsError and exception handling and faulttolerancee. Interaction and presentationf. Data persistence5. Software design notationsa. Structural descriptions (static)b. Behavioral descriptions (dynamic)6. Software design strategies and methods3. Software structure and architecturea. Architectural structures andviewpointsb. Architectural styles(macroarchitectural patterns)c. Design patterns (microarchitecturalpatterns)d. Families of programs and frameworksOctober 2010 v4StrengthWeaknessa.b.c.d.e.f.General strategiesFunction-oriented (structured) designObject-oriented designData-structure centered designComponent-based design (CBD)Other methods23
C. Software Construction: Knowledge1. Software construction fundamentalsa.b.c.d.Minimizing complexityAnticipating changeConstruction for verificationStandards in construction2. Managing constructiona. Construction methodsb. Construction planningc. Construction measurement3. Practical considerationsa.b.c.d.e.f.October 2010 v4Construction designConstruction languagesCodingConstruction testingConstruction qualityIntegrationStrengthWeakness24
C. Software Construction: Ability1. Software construction fundamentalsa.b.c.d.Minimizing complexityAnticipating changeConstruction for verificationStandards in construction2. Managing constructiona. Construction methodsb. Construction planningc. Construction measurement3. Practical considerationsa.b.c.d.e.f.October 2010 v4Construction designConstruction languagesCodingConstruction testingConstruction qualityIntegrationStrengthWeakness25
D. Software Testing: Knowledge1. Software testing fundamentalsa. Testing-related terminologyb. Key issuesc. Relationships of testing to other activities2. Test levelsa. The target of the testsb. Objectives of testing3. Test techniquesStrengthWeaknessa.b.c.d.e.f.g.Based on tester’s intuition and Usage-basedBased on nature of applicationSelecting and combining techniques4. Test-related measuresa. Evaluation of the program under testb. Evaluation of the tests performed5. Test processa. Management concernsb. Test activitiesOctober 2010 v426
D. Software Testing: Ability1. Software testing fundamentalsa. Testing-related terminologyb. Key issuesc. Relationships of testing to other activities2. Test levelsa. The target of the testsb. Objectives of testing3. Test techniquesStrengthWeaknessa.b.c.d.e.f.g.Based on tester’s intuition and Usage-basedBased on nature of applicationSelecting and combining techniques4. Test-related measuresa. Evaluation of the program under testb. Evaluation of the tests performed5. Test processa. Management concernsb. Test activitiesOctober 2010 v427
Evaluation Summary Strengths in all four evaluated SWEBOK areas Weaknesses in first two SWEBOK areas– A. Software Requirements– B. Software Design Knowledge may be satisfactory, but Abililtiesto perform are the real “proofs of the pudding” In general, the typical systems engineeringstudent did well as a “competent softwareengineer”.October 2010 v428
Classroom Observations (1 of 4)1. Some discussion required to clarify thedifferences between functional and nonfunctional requirements (system and SW).2. Initial definition of top-level use caseframework was weak, but then detailed usecase descriptions were well done.3. Allocation of system requirements tosoftware requirements was not easily done.4. Concept of a “CSCI” required discussion andproject experience to understand.October 2010 v429
Classroom Observations (2 of 4)5. Actually scripting a CSCI requirement wassurprisingly difficult.6. Object-oriented class modeling was weak –some students got it quickly, most did not.7. Structured analysis (Data Flow Diagrams)was not easy, but most students quicklylearned.8. Constructing state transition diagrams(STDs) was surprisingly difficult.October 2010 v430
Classroom Observations (3 of 4)9. Experience with Requirements TraceabilityMatrices was mixed General understanding and use was strong, but“Atomically” capturing and listing software(CSCI) requirements was weak.10. Following architecture and design patternswas strong, but creating new patterns wasweak.11. Object-oriented design and construction wasbi-modal – some got it, some didn’t.October 2010 v431
Classroom Observations (4 of 4)12. Behavior modeling (UML) was mixed Strong: Activity and Swim Lane DiagramsWeak: Control Flow, Sequence, and StateTransition Diagrams.13. Algorithm design (using PDL) was weak.14. Construction – coding and debugging – wasstrong in general.15. System integration and testing was strong.16. Project management and team work wasstrong.October 2010 v432
Conclusions and Recommendations NPS MSSE and SE4003 are, in general, goodpreparation for students to act as software engineers,but weaknesses may exist. Recommendations:– Prioritize the observed weaknesses and do a causalityanalysis.– For the high-priority (critical) weaknesses, determinewhich core courses (including SE4003) might needchanges.– Evaluate impact of proposed changes and determine abalanced curriculum update package.– Brief to curriculum sponsor, as required, and implementapproved changes.– Re-evaluate after several course offerings.October 2010 v433
Software Engineering: A Practitioner’s Approach (7 th Ed.) (Chapters 1 -10, 17-19) – Assigned readings and class presentations, exercises and discussions complement hands-on project experience. – Embedded System
7.2 American Strengths and Weaknesses 1. List three weaknesses of the Americans at the start of the war. 2. Besides patriotism, list two American strengths at the start of the war. 7.3 British Strengths and Weaknesses 1. List three s
Section 2 - American Strengths and Weaknesses The Patriots were in a weak position when the American Revolution began. They had a hastily organized, untrained army and a small navy. Their weaknesses were far more obvious than their strengths. American Weaknesses The Continen
strengths and weaknesses is not easy—in fact, it can be downright scary. Self-examination may reveal characteristics we don't really like about ourselves. Plus, some people have low self-esteem, so they are much more aware of their weaknesses than their strengths. It takes courage to evaluate yourself, acknowledge your strengths,
strengths and pick out in others listen to work with will help in. Spend more you provide examples of strengths is a way you know the definition of strengths is the labels for example, that my best and weaknesses. Lie of personal strengths and organization is why i get an. Sometimes the strengths and determined, describing the skills you are .
2.5.1 The importance of a strengths-based approach to leader or leadership development 18 2.5.1.1 Strengths-based coaching 19 2.5.2 Background to 'strengths' 20 2.5.3 Character strengths as defined by positive psychology 21 2.5.4 The VIA Strengths test 22 2.5.5 Critiques of a strengths-based approach 22 2.6 COACHING 23
Strengths, Weaknesses, Opportunities, and Threat (SWOT) Analysis Internal and external strengths and weaknesses should be considered at first if the company needs to do any strategy. Moreover, the opportunities Dior will face and what threats it will meet in recent
S.W.O.T. Analysis Identifying Your Strengths, Weaknesses, Opportunities, and Threats A SWOT analysis is a term used to describe a tool that is effective in identifying your Strengths and Weaknesses, and for examining the Opportunities and Threats you face.While it is a basic,
1. List at least two strengths and two weaknesses of each side at the start of the war for independence. American Strengths British Strengths American Weaknesses British Weaknesses 2. Complete the sentences for the map of Round 1 of Capture the Flag. The Blue team is smaller. It has
