Formal definitions written in the manual.  Written specification  External product of the Architect  Details what the user sees  Does not detail what.

Slides:



Advertisements
Similar presentations
EECE 310: Software Engineering Modular Decomposition, Abstraction and Specifications.
Advertisements

best practice project management methodology ©Platinum Services Group Limited What is XPRODi ?
Design Project (Last updated: Nov. 22/2010) Change since August 31: added the notes to the presentation in the next slide.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Slide 1 Systems Analysis and Design with UML Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination John Wiley.
Documenting a Software Architecture By Eng. Mohanned M. Dawoud.
PASSING THE WORD BY FRANKLYN OMORUAN. Written specifications Manual is the external specification of the product Manual is the external specification.
Steps, Tools, and Techniques
1 SWE 513: Software Engineering Requirements II. 2 Details in Requirements Requirements must be specific Examples -- university admissions system Requests.
8 September Announcements  GIT Class: Friday 3-5 SN 115 (Peter Parente)  Information for Project Links PageProject Links Page  Hot Topics Teams.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
User Documentation (no quiz) Tori Bowman CSSE 375 October 8 th, 2007.
Chapter 2: Algorithm Discovery and Design
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Operational Semantics.
IS Terms and Introductory Concepts. Contemplative Questions What is an information system? What is an information system? Why do we care about the difference.
Tom Hollander Solution Architect Solutions Development Centre Microsoft Australia ARC308.
Management Information Systems. (MIS)
Software Engineering Chapter 6 Software requirements
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
Chapter 2: Algorithm Discovery and Design
Chapter 4 After Green Light. After the Green Light Contractual Agreement Marketing Requirements Document (MRD) Project DefinitionBudget Project Approval.
1 Walk-in slide. 2 How to Manage a System Upgrade The Good, The Bad and The Ugly of Conversions David Cervelli Managing Consultant April 25, 2006.
Development plan and quality plan for your Project
Documentation 1. User Documentation 2. Technical Documentation 3. Program Documentation.
Chapter 6– Artifacts of the process
Presented by Collin Kanaley.  The manual is a necessary tool, but not a sufficient one.  The manual is the chief product of the architect.  It should.
Abstraction IS 101Y/CMSC 101 Computational Thinking and Design Tuesday, September 17, 2013 Carolyn Seaman University of Maryland, Baltimore County.
Chapter 4 – Requirements Engineering
Lori Smith Vice President Business Intelligence Universal Technical Institute Chosen by Industry. Ready to Work.™
1 CSBP430 – Database Systems Chapter 1: Databases and Database Users Mamoun Awad College of Information Technology United Arab Emirates University
Investigating System Requirements
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Configuration Management (CM)
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
Abstraction IS 101Y/CMSC 101 Computational Thinking and Design Tuesday, September 17, 2013 Marie desJardins University of Maryland, Baltimore County.
Martin Cryer Software Development. ‹#› Development Processes Traditional e.g. Waterfall Method Agile –Design Build (Quick to Market) –Combines Engineering,
Acceptance criteria vs. Functional requirements by Anna Dąbrowska.
Intermediate 2 Software Development Process. Software You should already know that any computer system is made up of hardware and software. The term hardware.
Lecture 6: Structural Modeling
Component 4: Introduction to Information and Computer Science Unit 9/Part a: Components and Development of Large Scale Systems.
Software from Requirements Brent Haines April 12, 2007 Why Methodology Doesn’t Really Matter.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Requirements Validation
Submitted To: Rutvi sarang Submitted By: Kushal Bhagat.
Issues in Ontology-based Information integration By Zhan Cui, Dean Jones and Paul O’Brien.
Software Engineering Chapter 6 Software requirements Ku-Yaw Chang Assistant Professor Department of Computer Science and Information.
Requirements Analysis
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
Course: Software Engineering – Design I IntroductionSlide Number 1 What is a specification Description of a (computer) system, which:  is precise;  defines.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Business and Systems Aligned. Business Empowered. TM Global ERP Projects Author:Andrew McCumiskey Presentation for:University of Birmingham Course: Commercial.
Software Design and Development Development Methodoligies Computing Science.
1 Use Cases Object-Oriented Modeling and Design with UML (Second Edition) Blaha & Rumbaugh Sections 7.1, 8.1.
Evolution of UML.
Algorithm and Ambiguity
CIS16 Application Development – Programming with Visual Basic
SMART EDU APP Technology to bridge the parent teacher gap.
Test Driven Lasse Koskela Chapter 9: Acceptance TDD Explained
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
Containerized Development with Eclipse Docker Tooling at scale
CSE403 Software Engineering Autumn 2000 Requirements
CSC 480 Software Engineering
Test Driven Lasse Koskela Chapter 9: Acceptance TDD Explained
Implementation Lessons Learned Application Security Summit 2007
Presentation transcript:

Formal definitions written in the manual

 Written specification  External product of the Architect  Details what the user sees  Does not detail what the user doesn’t see  Precession is the key  Multiple catalogued iterations that are dated and given version numbers  Definitions must all agree and state the essentials

 Precision beyond English  Formal Notation vs. Prose Language  Describes implementation of hardware and software  Prose and Formal can work together but one must be standard  Testing Formal Definitions by running it on a machine  Experts can easily and quickly have answers that are exact

 Good  Precise, Complete, Gaps are easier to spot  Bad  Comprehensibility  Ugly  Lack of precise definitions for particular instances

 Weekly Half-Day Meetings  Team made up of Architects, Leads on Software, Hardware, and Marketing  Small smart team can create many solutions to problems  Updates the manual  Annual or Bi-Annual Summits  Accumulated minor problems are dealt with  All project leaders are involved from all sections of the project

 Manuals are an important tool to keep things uniform and precise. Shortening the project time and developing a comprehensive knowledge of the project.