CS 435/535 ... to summarize
Topics • SW Development Processes • Software Evolution • Requirements Engineering • Verification and Validation • Use Cases • Software testing • UML • Error reporting and tracking • Patterns • Concept location • SW Architecture Patterns • Mining SW repositories • Design Patterns • UI development
What is Software Engineering? “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” • IEEE Standard 610.12: “The application of a systematic , disciplined, quantifiable approach to the development , operation , and maintenance of software ; that is, the application of engineering to software.” 2
Challenges • People – Understanding/knowledge, communication, capability • Size – Use cases/Features/Requirements – #people involved, #modules, #classes, #testcases – Diversity: customer, SW/HW environment • Time • Change 4
Cartoon Prof. Majumdar CS 130 Lecture 1 38
Problem #1: “How do we know it works?” • A specification allows us to: – Check whether software works – Build software in teams at all • Actually checking that software works is hard – Code reviews – Static analysis tools – Testing and more testing 40
Problem #2: “How do we code efficiently?” • Efficient development requires – Decomposing system into pieces • depends on what it does, how we build it, who does it – Good interfaces between pieces • The pieces should be large – Don’t try to break up into too many pieces • Interfaces are specifications of boundaries 52 – Must be well thought-out and well communicated
Observation • Software engineering boils down to several issues: – Specification: Know what you want to do – Design: Develop an efficient plan for doing it – Programming: Do it – Validation: Check that you have got what you wanted • Specifications are important – To even define what you want to do – To ensure everyone understands the plan 53
Software Engineering Layers Tools Methods Process • Process: framework of the required tasks – e.g., waterfall, extreme programming • Methods: technical “how to” – e.g., design review, code review, testing • Tools: automate processes and methods – Which software engineering tools do you know? 2
Processes • Waterfall • Rapid Prototyping • Iterative Models (Spiral) • Extreme Programming 10
XP Practices • On-site customer • Metaphor • Pair programming • The Planning Game • instant, complete code review – User stories • different point of view • Small releases • Collective ownership • Testing • Continuous integration – TDD • 40-hour week • Simple design • Coding standards – Just in time design – YAGNI 5 • Refactoring
XP Process Multiple short cycles (2 weeks): 1. Meet with client to elicit requirements • User stories + acceptance tests 2. Planning game • Break stories into tasks, estimate cost • Client prioritizes stories to do first 3. Implementation • Write programmer tests first • Simplest possible design to pass the tests • Code in pairs • Occasionally refactor the code 4. Evaluate progress and reiterate from step 1 6
Extreme Programming (XP) • XP: like iterative but taken to the extreme Time XP Waterfall Iterative Test Implement Design Analyze Scope 7
Agile Software Development • “Agile Manifesto” 2001 • “Scrum” project management + Extreme programming engineering practice • Idea: Build software incrementally, – using short 1-4 week iterations – Keep development aligned with changing needs Assess Select Outline planning and architectural Project closure design Review Develop 50 Sprint cycle
Software specification (or requirements engineering) The process of establishing what services are required and the constraints on the system’s operation and development. Requirements engineering process Feasibility study • Is it technically and financially feasible to build the system? Requirements elicitation and analysis • What do the system stakeholders require or expect from the system? Requirements specification • Defining the requirements in detail Requirements validation • Checking the validity of the requirements Sommerville: Ch 2.2.1, p36ff Chapter 2 Software Processes 15
The requirements engineering process Requirements Feasibility elicitation and study analysis Requirements specification Requirements Feasibility validation report System models User and system requirements Requirements document Chapter 2 Software Processes 16
Outcome • An agreed requirements document that specifies a system satisfying stakeholder requirements. • Two level of details User requirements: • End-users and customers need a high-level statement of the requirements. System Requirements: • System developers need a more detailed system specification. Chapter 2 Software Processes 17
Summary of Requirements Gathering • Find out what users/clients need – Not necessarily what they say they want • Use – Interviews – User stories – Straw man documents – Rapid prototyping – As appropriate . . .
Requirement vs. Specification • User Requirements – Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. • System Specifications – A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. • The distinction is often glossed over – Sommerville sees this as two levels of detail in the requirements document, the system requirements are a “functional specification” Ch 4, p83.
Specifications: theory & practice • In principle, specifications should be: – Unambiguous: • Only one way to interpret the spec – Complete • Include descriptions of all facilities required. – Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities. • In practice, it is almost impossible to produce a complete and consistent requirements document.
Requirements • How to write up requirements? – Informal, semi-formal, structured, formal • Requirements: functional vs non-functional • Goals vs verifiable non-func requirements • Requirements document vs design document • Structure of a requirements document 21
Use Case What it is: Text story Widely used to discover and record (mostly functional) requirements What is it about: Some actor(s) using a system to meet specific goals Answering questions: Who is using the system, what are their typical scenarios of use, and what are their goals? What it is NOT: Not object-oriented Not a diagram UML use cases diagrams are “secondary-value” artifacts Focus: use cases, not use case diagrams Historical: feature list (lacked context) -> use case
Use Case Format Brief Succinct one-paragraph summary usually the main success scenario done during early requirements analysis should take only a couple of minutes Casual informal paragraph format multiple paragraphs covering various scenarios Fully dressed details all steps and variations includes supporting sections such as preconditions and success guarantees mainly done after many use cases are identified and during early requirements workshop for high-value and high-risk requirements (e.g., core architectural)
Take an Actor and Actor-Goal Perspective Use case definition by Jacobson: “ A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor” Write requirements focusing on the users/actors of a system, asking about their goals and typical situations and what they consider a valuable result
How to Find Use Cases? Choose the system boundary what you are building? who will be using the system? what else will be used that you are not building? Find primary actors and their goals brainstorm the primary actors first who starts and stops the system? who gets notified when there are errors or failures? Define use cases that satisfy user goals prepare an actor-goal list (and not actor-task list) in general, one use case for each user goal name the use case similar to the user goal
What Tests Can Help Find Useful Use Cases? Rather than asking ”What is a valid use case?” More practical question: “What is a useful level of focus to express use cases for application requirements analysis?” Rules of thumb The Boss Test The EBP Test The size test
Use Cases form Basis for Others
UML: Unified Modeling Language or “Union of all Modeling Languages”? • We discuss – Use Case Diagrams for functional models – Class Diagrams for structural models – Object Diagrams – Sequence Diagrams – Activity Diagrams for dynamic models – State Diagrams • This is a subset of UML 9 – But probably the most used subset
UML Driven Process 54
Recommend
More recommend
