CSC450 Software Engineering

1. Devon M. Simmonds University of North Carolina, Wilmington Introduction to System Engineering CSC450Software Engineering

2. Outline • Introduction to system engineering • System engineering tasks • Need identification and scoping • Information gathering techniques • Workflow modeling with UML activity diagrams • Feasibility studies • Function/need allocation

3. System Engineering/Analysis • Software Lifecycle Activities Software Design Requirements Analysis Implementation System Engineering Testing • Systems Engineering • Identify needs/problems • Allocation of roles • Hardware • Procedures • Software • Feasibility studies Deployment Evolution

4. What is a System? • A system may be defined as a collection of interacting, interdependent components which act together in achieving some common goal. • Each component may itself be a system.

5. What is a System? • A business/computer-based system is usually composed of the following: • Software • Hardware • People • Documentation • Procedures

6. System Engineering • Software exists within some larger system • Encompassing system must be understood if software is to work properly within system • The domain is the general field of business or technology in which the clients will use the software • Domain analysis : the process by which a software engineer learns about the domain to better understand the problem: • A domain expert is a person who has a deep knowledge of the domain • Aviation System • What does it consist of?

7. System Engineering (2) • Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” • If the system exists within a business organization system engineering is referred to as business process engineering • Systems engineering is also called systems analysis.

8. System Engineering/Analysis Process • Systems engineering is a problem-solving activity concerned with modeling the system encompassing software. • System engineering process • Establishing the user’s need and the software scope • Conducting software project planning • Conducting a feasibility study • Allocating functions to hardware, software, people, database, etc.

9. System Engineering/Analysis Tasks • Need identification and scoping • Project planning • Feasibility study • Allocation of functions/needs to components • Hardware • Software • Procedures Allocating functions to software includes scoping!

10. System Engineering/Analysis: Need identification process • The need identification process involves: • Initial meetings • Information gathering • Document reviews, interviews, questionnaires, observations, measurements Information Gathering One on One Group meeting

11. System Analysis: Need identification process • The need identification process involves: • Initial meetings • Information gathering (Kendall & Kendall) • Document reviews, interviews, questionnaires, observations, measurements • Workflow modeling & analysis • Activity diagrams/dataflow diagrams using UML

12. Information Gathering Techniques

13. Information Gathering: Document Reviews • Why review documents anyway? • Often a useful point to start in the analysis process • Documentation typically available on various aspect of an organization • Advantages of document review: • Documentation is generally portable • Documentation is generally easily accessible • Disadvantages: • The volume of documentation may be large • Documentation is often inaccurate and outdated • Documentation is often sketchy. • Checklist of potential documents: • Manuals detailing company organization, policy and existing systems. • Manuals detailing job descriptions and staff duties and responsibilities. • Previous reports and investigations. • Publicity and promotional material.

14. Information Gathering:Interviews • An interview is a directed conversation that is goal-driven and uses a question-answer format. • Exit interview, phone interview, lunch interview, panel interview • Kinds of information sought • Facts • Opinions • Scenarios 1 conclusion? • Owner is overstating the facts? • Scenarios 2 conclusion? • Owner is NOT overstating the facts, she wants the problem with refunds addressed! Interview Scenarios (from Kendall & Kendall) Scenario 1: Systems Engineer: “How many customer refunds do you typically give per week?” Client: “About 20 to 25 per week” Facts: When you search available documentation, the average is only 10.5 per week. Question: What inferences can you draw? Scenario 2: Systems Engineer: “What are your major concerns related to customer refunds?” Client: “Customer refunds are way too high. We need to get it right the first time” Facts: When you search available documentation, the average is only 10.5 per week. Question: What inferences can you draw? The interview is probably the single most important tool in information gathering process.

15. Information Gathering:Interviews • Kinds of information sought • Facts • Opinions • Feelings • May reflect emotion, attitudes and organizational culture • Goals The interview is probably the single most important tool in information gathering process.

16. Information Gathering:Interview Planning • Five preparatory steps • Read background material • Establish interview objectives • Objectives address information sources, formats and quality, decision-making, client goals • Decide who to interview • Prepare the interviewee • Call, send email, set limit of 45-60 mins • Decide on type of questions and structure of questions The interview is probably the single most important tool in information gathering process.

17. Information Gathering:Interview Planning • Question types • Open-ended • Response not limited • Closed • Limits response • E.g. yes, no • Probes • Follow-up questions The interview is probably the single most important tool in information gathering process.

18. Information Gathering:Interview Planning • Question pitfalls • Avoid leading questions • You agree with other managers that Sales should be computerized, don’t you? • Do you think Sales should be computerized? • What do you think of computerizing sales? • Avoid double-barreled questions? • Why are projects outsourced, and how did you go about selecting the outsourcing process? The interview is probably the single most important tool in information gathering process.

19. Information Gathering:Interview Planning • Question formats – how to arrange questions • Pyramid structure • Inductive style • closed questions  open-ended questions • Funnel structure • Deductive style • Open-ended questions  closed questions • Diamond structure • Combination of first two Interviews may be recorded but be aware of the Hawthorne effect!

20. Job Interview Questions - Examples • What are your long-range goals and objectives? • What are the most important rewards you expect in your career? • What are your strengths, weaknesses, and interests? • Are you willing to travel? • How do you work under pressure? • Describe a situation in which you worked as part of a team. What role did you take on? What went well and what didn't?

21. Information Gathering:Questionnaires • A data gathering survey document with questions and space for answers. • Similar rules apply for question design and organization – with some differences • Allow ample white space – attractiveness • Allow adequate space for responses • Use scales where possible • List most important questions first • Cluster items of similar content together • Bring up less controversial items first Allocating functions to software includes scoping!

22. Information Gathering:Questionnaires • Scales • Nominal • Used to classify • Ordinal • Used to order or rank • Interval • Interval between items are equal • Ratio • Has an absolute zero Allocating functions to software includes scoping!

23. Information Gathering:Questionnaires • Nominal Data • Classification data • 1 = Computer Science • 2 = Psychology • 3 = Accounting • 4 = Chemistry • no ordering, e.g. it makes no sense to state that Psychology > Computer Science • arbitrary labels • Data can be counted but not ordered

24. Information Gathering:Questionnaires • Ordinal Data • Ordering but difference between values not important • 1 = Extremely Helpful • 2 = Very Helpful • 3 = Moderately Helpful • 4 = Not Very Helpful • 5 = Not Helpful At All • Data can be counted and ordered

25. Information Gathering:Questionnaires • Interval Data • Ordered, constant scale i.e. difference between values are equal • How many hours do dogs sleep at night? • 2 hours • 4 hours • 6 hours • 8 hours • Data may be added and subtracted but not multiplied or divided.

26. Information Gathering:Questionnaires • Ratio Data • Approximately how many hours do you spend on the computer daily? • 0 2 4 6 8 • Data may be added, subtracted, multiplied and divided.

27. Information Gathering:Constructing Scales: Validity & reliability • Validity • Does a question measure what it is intended to measure? • Reliability • Is the questionnaire consistent? Allocating functions to software includes scoping!

28. System Engineering Tasks • Need identification and scoping • Project planning • Feasibility study • Allocation of functions/needs to components • Hardware • Software • Procedures Allocating functions to software includes scoping!

29. Feasibility Study • A feasibility study is a preliminary study undertaken before the real work of a project starts to ascertain the likelihood of the project's success. It is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative. Wikipedia.com

30. Feasibility Study • Feasibility study subareas • Economic feasibility • Costs versus benefits • Technical feasibility • Analysis of human and technical resources • Legal Feasibility • Analysis of legal constraints and issues • Alternatives • Evaluation of alternative approaches to solving problem.

31. Feasibility Study • Feasibility study subareas • Economic feasibility • Are financial resources available? • Do cost/benefit analysis justify development? • Is the market ready for the product? • Technical feasibility • How difficult is it to build software? • Is required experience available? • Is required technology available? • Is time available to build software? • Legal Feasibility • What legal problems do we anticipate? • Are these problems surmountable? • Do we have legal counsel? • What are the cost implications of these problems? A feasibility study is not complete without an analysis of risks?

32. System Engineering Tasks • Need identification and scoping • Project planning • Feasibility study • Allocation of functions/needs to components • Hardware • Software • Procedures Allocating functions to software includes scoping!

33. Need Identification:Workflow Modeling • but first, the role of modeling in engineering software.

34. Role of Models in Engineering • To help us understand complex systems • Useful for both requirements and designs • Minimize risk by detecting errors and omissions early in the design cycle (at low cost) • Through analysis and experimentation • Investigate and compare alternative solutions • To communicate understanding • Stakeholders: clients, users, implementers, testers, documenters, etc. • To drive implementation • The model as a blueprint for construction

35. Functional Model Modeled system Engineering Models • Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint Functional System Modeled System • We do not see everything at once • We see a representation that is easily understood for the purpose at hand

36. New Hanover Regional Medical Center First Floor Model Doghouse Skyscraper Models in other disciplines • How models help • Focus on what is important • Essential complexity, accidental complexity • Mitigate risks • Ensure quality • Models vary in complexity • A model is a representation of an item • A model does not show all the features • A model is anabstraction: abstraction = hide details

37. Models in other disciplines 2005 Champions • A - Making a V-cut to get the ball. B - Receiving Inside Hand-off. Roy Williams

38. What characteristics should a useful model possess? • …

39. Characteristics of Useful Models • Abstract • Emphasize important aspects while removing irrelevant ones • Understandable • Expressed in a form that is readily understood by observers • Accurate • Faithfully represents the modeled system • Predictive • Can be used to answer questions about the modeled system • Inexpensive • Much cheaper to construct and study than the modeled system

40. “Software has the rare property that it allows us to directly evolve models into full-fledged implementations without changing the engineering medium, tools, or methods!” - Bran Selic The Remarkable Thing About Software • The model evolves into the system it models

41. The Unified Modeling Language • The UML is a standard diagramming language to visualize the results of analysis and design. • UML is a tool • Learning how to create high-quality models is not equivalent to learning the UML • UML is simply a language for expressing models • The UML is not • a process or methodology • an object-oriented analysis and design technique • a modeling technique

42. UML Goals • Define an easy-to-learn but semantically rich visual modeling language • Unify the Booch, OMT, and Objectory modeling languages • Include ideas from other modeling languages • Incorporate industry best practices • Address contemporary software development issues • scale, distribution, concurrency, executability, etc. • Provide flexibility for applying different processes

43. LINK UML Specification UML 2.0 Diagram Types • Class diagrams • Activity diagrams • State machines • Sequence diagrams • Object diagrams • Component diagrams • Deployment diagrams • Package diagrams • etc. 14 types altogether

44. Need Identification:Workflow Modeling • Workflow is a description of work done, tasks performed, the order in which tasks are performed, who performs tasks, how tasks are structured and synchronized and the input and output of activities. • In UML, workflows may be described using Activity Diagrams.

45. Summary • In this class we discussed • What is system engineering • System engineering tasks • Need identification and scoping • Information gathering techniques • Workflow modeling with UML activity diagrams • Feasibility studies • Function/need allocation • Brief overview of UML

46. Qu es ti ons? Summary • What’s coming next class? ______________________ Devon M. Simmonds Computer Science Department University of North Carolina Wilmington _____________________________________________________________