CSE 350 - Software Design and Engineering Jonathan M. Smith 2/13/2001.

Slides:



Advertisements
Similar presentations
Software Development Lifecycle & Release Management Scottie Cheng.
Advertisements

Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Documentation Letts Study Guide Information Systems - IT Chapter 19.
Documentation 1 Comprehending the present – Investing in the future.
1 SWE 513: Software Engineering Requirements II. 2 Details in Requirements Requirements must be specific Examples -- university admissions system Requests.
API Design CPSC 315 – Programming Studio Fall 2008 Follows Kernighan and Pike, The Practice of Programming and Joshua Bloch’s Library-Centric Software.
1 Introduction to Software Engineering Lecture 42 – Communication Skills.
Chapter 3: System design. System design Creating system components Three primary components – designing data structure and content – create software –
CSE1301 Computer Programming: Lecture 13 Documentation.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)
Fall 2007CS 2251 Software Engineering Intro. Fall 2007CS 2252 Topics Software challenge Life-cycle models Design Issues Documentation Abstraction.
CS CS 5150 Software Engineering Lecture 20 Acceptance and Delivery.
Modules, Hierarchy Charts, and Documentation
CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: April 16 th, 2002.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 26 Delivering the System.
20 February Detailed Design Implementation. Software Engineering Elaborated Steps Concept Requirements Architecture Design Implementation Unit test Integration.
Software Documentation Written By: Ian Sommerville Presentation By: Stephen Lopez-Couto.
Process-oriented System Automation Executable Process Modeling & Process Automation.
CH07: Writing the Programs Does not teach you how to program, but point out some software engineering practices that you should should keep in mind as.
DCT 1123 PROBLEM SOLVING & ALGORITHMS INTRODUCTION TO PROGRAMMING.
Software Construction. Implementation System Specification Requirements Analysis Architectural Design Detailed Design Coding & Debugging Unit Testing.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
1 Software Construction Software Construction Chapter 1.
Design-Making Projects Work (Chapter7) n Large Projects u Design often distinct from analysis or coding u Project takes weeks, months or years to create.
Software Engineering General architecture. Architectural components:  Program organisation overview Major building blocks in a system Definition of each.
Programming Lifecycle
Statistics Monitor of SPMSII Warrior Team Pu Su Heng Tan Kening Zhang.
Systems Development Lifecycle Testing and Documentation.
The Software Development Life Cycle. Software Development SDLC The Software Development Life-Cycle Sometimes called the program development lifecycle.
1 ENERGY 211 / CME 211 Lecture 26 November 19, 2008.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
SE: CHAPTER 7 Writing The Program
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
1 Ch. 1: Software Development (Read) 5 Phases of Software Life Cycle: Problem Analysis and Specification Design Implementation (Coding) Testing, Execution.
Input Design Lecture 11 1 BTEC HNC Systems Support Castle College 2007/8.
Slide 1 Shall Lists. Slide 2 Shall List Statement Categories Functional Requirements User Interface Requirements Performance Requirements Qualification.
CSCI 1100/1202 April 1-3, Program Development The creation of software involves four basic activities: –establishing the requirements –creating.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
CS 5150 Software Engineering Lecture 2 Software Processes 1.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 26 Delivering the System.
Software Engineering Issues Software Engineering Concepts System Specifications Procedural Design Object-Oriented Design System Testing.
ACT476 CAPSTONE WRITING AN USER MANUAL. Developers VS Users Developers want to write code Have little time to document or write user’s manuals Users on.
CS223: Software Engineering Lecture 16: The Agile Methodology.
Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009.
Equations for Ecademy Client: ISU Computation Center Faculty Advisor: Dr. Robert Anderson Technical Advisor: Dr. Pete Boysen Team Members:  Tim Arganbright,
CompSci Today’s topics Industry Practice Software Engineering Upcoming The Killer Robot Reading Great Ideas, Chapters 7.
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.
Project Management Methodology Project Closing. Project closing stage Must be performed for all projects, successfully completed or shut off by management.
1 Chapter 1- Introduction How Bugs affect our lives What is a Bug? What software testers do?
CS646: Software Design and Architectures Introduction and Overview †  Definitions.  The general design process.  A context for design: the waterfall.
Learning Objectives Today we will Learn: The different methods of implementation The differences between user and technical documentation.
Defect Example : The Coin Problem
Software Construction
Learning to Program D is for Digital.
HSA Reusability Issues
The Software Development Cycle
Understand the Programming Process
Software Construction
Software Construction
Understand the Programming Process
Software Construction
PPT and video are due no later than March 1, 2019
Chapter 2. Problem Solving and Software Engineering
Software Construction Dr. Samer Odeh Hanna (PhD)
Software Construction
The COSMO Coding Standards Some Highlights
Software Construction
The Software Development Cycle
Presentation transcript:

CSE Software Design and Engineering Jonathan M. Smith 2/13/2001

Administrative lSolaris may not support inet_pton() l266 Moore - dual SCSI boxes a problem for OpenBSD. lSTATUS as of 3AM - things are broken lCode: (but nothing works :-( lHighest priority

Documentation lWhat’s it used for? lWhat forms does it take? lHow does it affect the software lifecycle? lWhat effect does it have on costs? lWhy do people NOT document?

What is documentation for? lInternal memory of what system does - design decisions / tradeoffs - implementation of algorithms - data structures / input formats, etc. lExternal interfaces of system - inputs, outputs, control fields - error-handling conditions

Forms of documentation lManuals / man pages lUser’s Guides lDesign Documents / change-logs lBuilt-in help lComments lCoding rules / object-naming

Manuals and User’s Guides lManuals are precise and complete lUser’s guides are more application- centered lMust focus on external interface lReveal as little about internals as possible (“malloc() badness”)

Design Documents/Change Logs lFocus is on assumptions, justification of choices, description of choices lLevel of detail varies lArchival history of system lChange log details this -Explicit, or CVS/RCS/SCCS lInternals versus Externals

Built-in help lDocumentation as part of program lAdvantage: always there lCan be invoked as exception lMay be as simple as a usage message lCan be associated with error handling

Comments / Coding Rules lSource-embedded documentation -associated with source - not for users (except with open source :-) lBest: Big blocks of description + little notes for anything obscure lCoding rules can help, e.g. variable naming, named constants, etc.

Effect on Software Lifecycle lReduces 1-1 communication lProvides means of rapid “ramp-up” for “trainees” / “newbies” lProvides reference for testing lProvides “memory” for when modification requests occur during maintenance

Effects on Costs lDocumentation more expensive short- term, cheaper long-term -May have separate documentation team lEffects on lifecycle => big savings lAnd, good documentation increases user acceptance and hence income!

Why don’t programmers document? lPersonality types (communications skill deficits, “non-verbal”) lEasier to feel complete when it works lChallenge of keeping documentation up to date with code lDon’t like typing :-)