Lecture 6: Writing the Project Documentation Part IV.

Slides:



Advertisements
Similar presentations
Technical System Options
Advertisements

Configuration Management
English & Communications for College
1 Information Systems Development (ISD) Systems Development Life Cycle Overview of Analysis Phase Overview of Design Phase CP2236: Information Systems.
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
July 11 th, 2005 Software Engineering with Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 16, 17 and 18 Fred Durão.
Technical Writing II Acknowledgement: –This lecture notes are based on many on-line documents. –I would like to thank these authors who make the documents.
1 Introduction to Software Engineering Lecture 42 – Communication Skills.
CPRJ2003 Systems Development Group Project
Project Life Cycle Jon Ivins DMU. Introduction n Projects consist of many separate components n Constraints include: time, costs, staff, equipment n Assets.
Feedback from Usability Evaluation to User Interface Design: Are Usability Reports Any Good? Christian M. Nielsen 1 Michael Overgaard 2 Michael B. Pedersen.
Lecture 3: Writing the Project Documentation Part I
Collaborative Report Writing the Proposal. Definition Proposal: a document written to convince your audience to adopt an idea, a product, or a service.
System Implementation
Lecture 2: Project Concept Document
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
"In the name of ALLAH, most Gracious, most Compassionate".
Bret Juliano. Introduction What Documentation is Required? – To use a program – To believe a program – To modify a program The Flow-Chart Curse Self-Documenting.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
1 Shawlands Academy Higher Computing Software Development Unit.
Module CC3002 Post Implementation Issues Lecture for Week 1 AY 2013 Spring.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Where Should I Be Now??? Finished corrections to task a/b Annotated a page of code and put it in folder Put evidence of manual code changes (edit and add)
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
BTEC Unit 06 – Lesson 08 Principals of Software Design Mr C Johnston ICT Teacher
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
GE 121 – Engineering Design Engineering Design GE121 Reporting the Outcome Lecture 7A.
Scientific Communication
GettingUsers Started Getting Users Started Instructor: Glenda H. Easter ITSW 1410, Presentation Media Software.
Controlled Assessment A(iii) Recommended solution Recommended solution Reasons for this recommendation Refer to the information requirements and your research.
Intermediate 2 Software Development Process. Software You should already know that any computer system is made up of hardware and software. The term hardware.
Disciplined Software Engineering Lecture #2 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #2 Software Engineering.
The Software Development Process
Part One The Forms of Software Documentation Chapter2: Writing to Teach- Tutorials Chapter3: Writing to Guide- Procedures Chapter4 : Writing to Support-
The Other Face Or Why Document? By Chris Bradney Or Why Document? By Chris Bradney.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
Final Year Project (FYP) 1
Critical Design Review (CDR)
Building Software Solutions Documentation for Users Notes are from: Wilson, Software Design and Development The Preliminary Course. Cambridge Press.
M4 BTEC Level 3 Subsidiary Diploma in ICT. Technical Documentation The technical documentation may be a section in the user documentation or could be.
Mark Dixon 1 Tech – Final Report. Mark Dixon 2 Aims & Objectives Give guidance on: –Project Report –Demonstration.
Evaluating Requirements
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Completing Assignment 3. Step 1- Create A Feedback Form (P5) You need to create a blank form for 5 people to: – Review each of the three graphics (at.
Lecture Exam 1 Study Guide Albert Kalim. Chapter 1: Computer Basics 1. Explain why it’s essential to learn about computers today. 2. Discuss several ways.
1 Geant4 Documentation Dennis Wright Geant4 Delta Review 9 October 2002 Internal documentation review Documentation improvements Plans for future improvements.
44222: Information Systems Development Prototyping & The Problem Statement Ian Perry Room: C49 Extension: 7287
By the end of this lesson you will be able to explain: 1. Identify the support categories for reported computer problems 2. Use Remote Assistance to connect.
CMPT 275 TEAM DIRECTORIES. One Sentence Summary The Study Buddy is: a tool to help users study to improve their grades by simulating a multiple choice.
Learning Objectives Today we will Learn: The different methods of implementation The differences between user and technical documentation.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Software Configuration Management
System Design, Implementation and Review
COMP390/3/4/5 Final Year Project Demonstration & Dissertation
Gary Hughes, South Oakleigh College
COMP390/3/4/5 Final Year Project Demonstration & Dissertation
How to Use References Chapter 4.
Documentation for Developers
COMP390/3/4/5 Final Year Project Demonstration & Dissertation
Writing reports Wrea Mohammed
Research Methods Technical Writing Thesis Report Writing
Geant4 Documentation Geant4 Workshop 4 October 2002 Dennis Wright
COMP390/3/4/5 && COMP593 Final Year Projects Demonstration & Dissertation Irina Biktasheva
COMP390/3/4/5 Final Year Project Demonstration & Dissertation
Presentation transcript:

Lecture 6: Writing the Project Documentation Part IV

Documenting Software Issues covered in Software Documentation Internal commenting of program code System’s analysis and design notes Figures and system’s documentation Test plans User guides

Documenting Software List of topics and documentation you might be expected to cover and include in your project: An introduction / Overview Technical solution adopted Design: System analysis, system design, human factors, etc Software engineering information: Structure, definition languages and test plans Development approach used Problem encountered Limitations / restrictions Hardware/software requirements Next stage Evaluation of the project User guide

Documenting Software Commenting Program Code Dependant on the programming language used Guidelines to follow when commenting your program code: Understand the purpose of the program you are writing Try to ensure you provide the right level of comments within your program. Don’t over-comment or under-comment. And avoid commenting on every line in the code It is advisable to comment each function, procedure, object, block, screen, etc. This will explain how each component of your program work. Try to make your comments separated from your code. Use widely the separate line comments, instead of in-line comments

Documenting Software Commenting Program Code Continue: Guidelines to follow when commenting your program code: Keep your comments brief and clear. Don’t waste time in producing fancy comments. Comments are added to enhance understanding of your program not to make it prettier. Make sure that you add vital information at the beginning of your program, such as: author, date, version number, description of what the program does, and brief explanation of how it does it. Make sure to update your comments if you have modified your code

Documenting Software Writing User Guides Any user guides you develop are likely to be presented within separate document to your final report, or included within its appendices. The longer user guides are, the more sensible it will be to produce them in separate document.

Documenting Software Writing User Guides A user guide, should provide the user with the following information: An overview of the software An idea of its hardware requirements (memory, disk space, additional hardware requirements such as, sound cards, operating system requirements, etc. How to install the software How to start the software How to end or uninstall the software Details of any known problems and restrictions imposed by the program

Documenting Software Writing User Guides A user manual, should satisfy three aims: To provide practical information about the software when help is not at hand To help inexperienced users get started quickly and with least difficulty To help experienced users become productive quickly