CS 435/535 ... to summarize Topics SW Development Processes - - PowerPoint PPT Presentation
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
Validation
2
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.”
“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”
Challenges
– Understanding/knowledge, communication, capability
– Use cases/Features/Requirements – #people involved, #modules, #classes, #testcases – Diversity: customer, SW/HW environment
4
Cartoon
38
40
Problem #1: “How do we know it works?”
– Check whether software works – Build software in teams at all
– Code reviews – Static analysis tools – Testing and more testing
52
Problem #2: “How do we code efficiently?”
– Decomposing system into pieces
– Good interfaces between pieces
– Don’t try to break up into too many pieces
– Must be well thought-out and well communicated
53
Observation
– 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
– To even define what you want to do – To ensure everyone understands the plan
2
Software Engineering Layers
– e.g., waterfall, extreme programming
– e.g., design review, code review, testing
– Which software engineering tools do you know?
Process Methods Tools
Processes
10
5
XP Practices
– User stories
– TDD
– Just in time design – YAGNI
6
XP Process
Multiple short cycles (2 weeks):
7
Extreme Programming (XP)
Scope Time Analyze Design Implement Test Waterfall Iterative XP
Agile Software Development
+ Extreme programming engineering practice
– using short 1-4 week iterations – Keep development aligned with changing needs
50 Outline planning and architectural design Project closure Assess Select Review Develop Sprint cycle
Chapter 2 Software Processes
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
15
Sommerville: Ch 2.2.1, p36ff
Chapter 2 Software Processes
The requirements engineering process
Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document
16
Chapter 2 Software Processes
Outcome
User requirements:
statement of the requirements.
System Requirements:
specification.
17
Summary of Requirements Gathering
– Not necessarily what they say they want
– Interviews – User stories – Straw man documents – Rapid prototyping – As appropriate . . .
Requirement vs. Specification
– Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
– 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.
– Sommerville sees this as two levels of detail in the requirements document, the system requirements are a “functional specification” Ch 4, p83.
– Unambiguous:
– Complete
– Consistent
descriptions of the system facilities.
complete and consistent requirements document.
Requirements
– Informal, semi-formal, structured, formal
21
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
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)
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
Write requirements focusing
on the users/actors of a system, asking about their goals and typical situations and what they consider a valuable result
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
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
9
UML: Unified Modeling Language
– Use Case Diagrams for functional models – Class Diagrams – Object Diagrams – Sequence Diagrams – Activity Diagrams for dynamic models – State Diagrams
– But probably the most used subset for structural models
54
UML Driven Process
65
Opinions about UML: What’s Good
– Makes it easier to share requirements, specs, designs
– A (good) picture is worth 1000 words – For the non-technical, easier to grasp simple diagrams than simple pseudo-code
– Much better than natural language
– Something natural language could never have
66
Opinions On UML: What’s Bad
– Union of most popular modeling languages – Sublanguages remain largely unintegrated
– Many details are hard to depict visually
– No visualization advantage for large diagrams
Software architecture
– Design Process for
systems making up a system and
system control and communication
– Output of this design process:
software architecture
design process
specification and design processes
some specification activities
system components and their communications
Common architectural styles (patterns) Garlan & Shaw:
architectures
(implicit invocation)
Sommerville
Software Design Patterns from CS 301 1.Iterator 2.Observer 3.Strategy 4.Composite 5.Decorator 6.Template 7.Singleton
34
also in Horstmann’s book
Software Design Patterns in CS 435 1.Iterator 2.Observer 3.Strategy 4.Composite 5.Decorator 6.Template 7.Singleton
35
also in Horstmann’s book
Version Control Systems: SVN, GIT
36
Image from http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
SVN using branches
distributed version control systems
projects (e.g., Linux kernel)
Software Evolution
documenting software to make it easier to change
the evolution strategy that is used
39
Verification: Are we building the product right?
– To which degree is the implementation consistent with its (formal or semi-formal) specification? – Testing, inspections, static analysis, …
Validation: Are we building the right product?
– To which degree does the software fulfill its (informal) requirements? – Usability, feedback from users, …
6
Testing: run software to try and generate
Static verification: identify (specific)
Inspection/review/walkthrough:
Formal proof: proving that the program
10
Testing
– Purpose: reveal failures – Limits: small subset of the domain (=> risk of inadequate test set)
Static verification
– Purpose: consider all program behaviors (and more) – Limits: false positives, may not terminate
Review
– Purpose: systematic in detecting defects – Limits: informal
Proof
– Purpose: prove correctness – Limits: complexity/cost (requires a formal spec)
11
3
some fault
requirements or other description of the expected behavior
program that contain the fault must be reached
PIE model
– Find important bugs
– When testing the prototype or straw man
11
“Program testing can be a very efgective way to show the presence of bugs but is hopelessly inadequate for showing their absence” [Dijkstra]
– Only validation technique for non-functional requirements – Should be used in conjunction with static verification to provide full V&V coverage
validation, functional/system, acceptance, alpha/beta, regression, security, performance, stress
concolic testing, hybrid concolic testing
46
– check for duplicates, – precise system and usage description, – expected and
– reproducibility – symptoms vs suspected causes
47
Software Reconn SPR ASDGs LSI NLP Cerberus PROMESIR SITIR SNIAFL DORA FCA
Static Textual Dynamic
Dit, Revelle, Gethers and Denys Poshyvanyk. “Feature Location in Source Code: A Taxonomy and Survey.” Submission to Journal of Software Maintenance and Evolution: Research and Practice.
SUADE
Mining SW Repositories
– developers who changed this also changed that
– derive set of rules from historical changes – recognize entities that are frequently change together – Rule: support vs confidence – Quality of recommendation system: precision vs recall
49
UI design
– Familiarity, Consistency, Minimal Surprise, Recoverability from Errors, User Guidance
– Place the user in control – Reduce the user’s memory load – Be consistent
– often deal with the organization of too much information for too little space / human capability
50
UI Patterns: Overview of Examples
51
Processes
Validation
tracking