1 / 46

CSC450 Software Engineering

Devon M. Simmonds University of North Carolina, Wilmington . Introduction to System Engineering. CSC450 Software Engineering. Outline. Introduction to system engineering System engineering tasks Need identification and scoping Information gathering techniques

maina
Download Presentation

CSC450 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 _____________________________________________________________

More Related