CS代写:COMP354SoftwareDesign


根据软件工程中的程序设计流程,编写文档完成软件开发模板中的每一个软件开发的流程步骤。

Software Design Document (SDD) Template

Software design is a process by which the software requirements are translated
into a representation of software components, interfaces, and data necessary
for the implementation phase. The SDD shows how the software system will be
structured to satisfy the requirements. It is the primary reference for code
development and, therefore, it must contain all the information required by a
programmer to write code. The SDD is performed in two stages. The first is a
preliminary design in which the overall system architecture and data
architecture is defined. In the second stage, i.e. the detailed design stage,
more detailed data structures are defined and algorithms are developed for the
defined architecture.
This template is an annotated outline for a software design document adapted
from the IEEE Recommended Practice for Software Design Descriptions. The IEEE
Recommended Practice for Software Design Descriptions have been reduced in
order to simplify this assignment while still retaining the main components
and providing a general idea of a project definition report. For your own
information, please refer to IEEE Std 1016-1998 for the full IEEE Recommended
Practice for Software Design Descriptions.

Introduction

Purpose

Identify the purpose of this SDD and its intended audience. (e.g. “This
software design document describes the architecture and system design of
XX..”).

Scope

Provide a description and scope of the software and explain the goals,
objectives and benefits of your project. This will provide the basis for the
brief description of your product.

Overview

Provide an overview of this document and its organization.

Reference Material

This section is optional.
List any documents, if any, which were used as sources of information for the
test plan.

Definitions and Acronyms

This section is optional.
Provide definitions of all terms, acronyms, and abbreviations that might exist
to properly interpret the SDD. These definitions should be items used in the
SDD that are most likely not known to the audience.

System Overview

Give a general description of the functionality, context and design of your
project. Provideany background information if necessary.

System Architecture

Architectural Design

Develop a modular program structure and explain the relationships between the
modules to achieve the complete functionality of the system. This is a high
level overview of how responsibilities of the system were partitioned and then
assigned to subsystems. Identify each high level subsystem and the roles or
responsibilities assigned to it. Describe how these subsystems collaborate
with each other in order to achieve the desired functionality. Don’t go into
too much detail about the individual subsystems. The main purpose is to gain a
general understanding of how and why the system was decomposed, and how the
individual parts worktogether. Provide a diagram showing the major subsystems
and data repositories and their interconnections. Describe the diagram if
required.

Decomposition Description

Provide a decomposition of the subsystems in the architectural design.
Supplement with text as needed. You may choose to give a functional
description or an object-oriented description.
For a functional description, put toplevel data flow diagram (DFD) and
structural decomposition diagrams. For an OO description, put subsystem model,
object diagrams, generalization hierarchy diagram(s) (if any), aggregation
hierarchy diagram(s) (if any), interface specifications, and sequence diagrams
here.

Design Rationale

Discuss the rationale for selecting the architecture described including
critical issues and trade/offs that were considered. You may discuss other
architectures that were considered, provided that you explain why you didn’t
choose them.

Data Design

Data Description

Explain how the information domain of your system is transformed into data
structures.
Describe how the major data or system entities are stored, processed and
organized. List any databases or data storage items.

Data Dictionary

Alphabetically list the system entities or major data along with their types
and descriptions. If you provided a functional description, list all the
functions and function parameters. If you provided an OO description, list the
objects and its attributes, methods and method parameters.

Component Design

In this section, we take a closer look at what each component does in a more
systematic way. If you gave a functional description, provide a summary of
your algorithm for each function listed in procedural description language
(PDL) or pseudocode. If you gave an OO description, summarize each object
member function for all the objects listed in PDL or pseudocode. Describe any
local data when necessary.

Human Interface Design

Overview of User Interface

Describe the functionality of the system from the user’s perspective. Explain
how the user will be able to use your system to complete all the expected
features and the feedback information that will be displayed for the user.

Screen Images

Display screenshots showing the interface from the user’s perspective. These
can be hand-drawn or you can use an automated drawing tool. Just makethemas
accurate as possible. (Graph paper works well.)

Screen Objects and Actions

A discussion of screen objects and actions associated with those objects.

Requirements Matrix

Provide a cross-reference that traces components and data structures to the
requirements in your SRS document.
Use a tabular format to show which system components satisfy each of the
functional requirements from the SRS. Refer to the functional requirements by
the numbers/codes that you gave them in the SRS.

Appendices

This section is optional.
Appendices may be included, either directly or by reference, to provide
supporting details that could aid in the understanding of the Software Design
Document.


文章作者: SafePoker
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 SafePoker !
  目录