1
SoftwareEngineeringProjectReport
A Sample Document for
Generating Consistent Professional Reports
Prepared by
John T. Bell
for use in CS 440
at the
University of Illinois Chicago
September 2013
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
SOFTWARE ENGINEERING PROJECT REPORT, Study Guides, Projects, Research of Software Project Management
IT IS A REPORT OF HOW TO PREPARE THE PROJECT REPORT.
Typology: Study Guides, Projects, Research
2020/2021
1 / 78
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download SOFTWARE ENGINEERING PROJECT REPORT and more Study Guides, Projects, Research Software Project Management in PDF only on Docsity!
Software Engineering Project Report
A Sample Document for
Generating Consistent Professional Reports
Prepared by
John T. Bell
for use in CS 440
at the
University of Illinois Chicago
September 2013
How to Use This Document
This document is intended as a sample template that can be copied and edited to suit a particular software engineering project. It was assembled from a combination of documents [1], [2], and [3].
Styles
This document was written in Microsoft Word, and makes heavy use of styles. The styles dialog is initially located on the menu bar under the “Home” tab in MS Word. It is recommended that the styles dialog be pulled off into a separate window when working on formatting of the document. If each paragraph is assigned a style, then modifying that particular style will affect all paragraphs in the document having the same style.
The table of contents uses the document headings and sub-headings to automatically generate table of contents information.
Tracking Changes and Multiple Authors
The “Review” tab in MS Word contains several tools that are of particular use when editing large documents, particularly when multiple authors are involved:
The “Tracking” section allows you to track the ( proposed ) changes to a document, and to step through each proposed change to either accept or reject the proposed changes.
The “Compare” section allows you to merge changes proposed by different authors, ( which will be marked in separate colors for identification ), and then to use the change tracking tools described above to accept or deny each change.
The recommended procedure is to start with each author having a copy of a base document, ( possibly this template. ) Then each author changes the section(s) they are responsible for, and submits their changed version to one person who acts as the overall document editor. This author merges the changes, selectively accepts or rejects each change, and then distributes a new base document to all authors for the next round of changes. It is also possible to merge the changes and then distribute the document, so that all authors can review the proposed changes. ( The latter approach may be appropriate for documents such as bylaws, in which the changes must be approved by a committee or a vote before they can be accepted. )
Table of Contents
- How to Use This Document - List of Figures................................................................................................................... - List of Tables - I Project Description
- 1 Project Overview
- 2 The Purpose of the Project
- 2a The User Business or Background of the Project Effort.........................................
- 2b Goals of the Project
- 2c Measurement
- 3 The Scope of the Work
- 3a The Current Situation
- 3b The Context of the Work
- 3c Work Partitioning....................................................................................................
- 3d Competing Products
- 4 Product Scenarios
- 4a Product Scenario List
- 4b Individual Product Scenarios
- 5 Stakeholders
- 5a The Client................................................................................................................
- 5b The Customer
- 5c Hands-On Users of the Product
- 5d Priorities Assigned to Users
- 5e User Participation....................................................................................................
- 5f Maintenance Users and Service Technicians
- 5g Other Stakeholders
- 6 Mandated Constraints
- 6a Solution Constraints
- 6b Implementation Environment of the Current System
- 6c Partner or Collaborative Applications
- 6d Off-the-Shelf Software
- 6e Anticipated Workplace Environment
- 6f Schedule Constraints
- 6g Budget Constraints
- 7 Naming Conventions and Definitions
- 7a Definitions of Key Terms
- 7b UML and Other Notation Used in This Document
- 7c Data Dictionary for Any Included Models
- 8 Relevant Facts and Assumptions
- 8a Facts
- 8b Assumptions
- II Requirements
- 9 Product Use Cases
- 9a Use Case Diagrams
- 9b Product Use Case List
- 9c Individual Product Use Cases
- 10 Functional Requirements
- 11 Data Requirements
- 12 Performance Requirements
- 12a Speed and Latency Requirements
- 12b Precision or Accuracy Requirements
- 12c Capacity Requirements
- 13 Dependability Requirements
- 13a Reliability Requirements
- 13b Availability Requirements...................................................................................
- 13c Robustness or Fault-Tolerance Requirements.....................................................
- 13d Safety-Critical Requirements
- 14 Maintainability and Supportability Requirements..........................................................
- 14a Maintenance Requirements
- 14b Supportability Requirements
- 14c Adaptability Requirements
- 14d Scalability or Extensibility Requirements
- 14e Longevity Requirements
- 15 Security Requirements....................................................................................................
- 15a Access Requirements
- 15b Integrity Requirements
- 15c Privacy Requirements
- 15d Audit Requirements.............................................................................................
- 15e Immunity Requirements
- 16 Usability and Humanity Requirements
- 16a Ease of Use Requirements...................................................................................
- 16b Personalization and Internationalization Requirements
- 16c Learning Requirements
- 16d Understandability and Politeness Requirements
- 16e Accessibility Requirements
- 16f User Documentation Requirements
- 16g Training Requirements
- 17 Look and Feel Requirements
- 17a Appearance Requirements...................................................................................
- 17b Style Requirements
- 18 Operational and Environmental Requirements
- 18a Expected Physical Environment..........................................................................
- 18b Requirements for Interfacing with Adjacent Systems.........................................
- 18c Productization Requirements
- 18d Release Requirements
- 19 Cultural and Political Requirements
- 19a Cultural Requirements.........................................................................................
- 19b Political Requirements
- 20 Legal Requirements
- 20a Compliance Requirements
- 20b Standards Requirements
- 9 Product Use Cases
- III Design
- 21 System Design
- 21a Design goals
- 22 Current Software Architecture
- 23 Proposed Software Architecture
- 23a Overview
- 23b Class Diagrams
- 23c Dynamic Model
- 23d Subsystem Decomposition
- 23e Hardware / software mapping
- 23f Data Dictionary
- 23g Persistent Data management
- 23h Access control and security
- 23i Global software control
- 23j Boundary conditions
- 24 Subsystem services
- 25 User Interface
- 26 Object Design
- 26a Object Design trade-offs
- 26b Interface Documentation guidelines....................................................................
- 26c Packages
- 26d Class Interfaces
- 21 System Design
- IV Test Plans........................................................................................................................
- 27 Features to be tested / not to be tested
- 28 Pass/Fail Criteria
- 29 Approach
- 30 Suspension and resumption
- 31 Testing materials ( hardware / software requirements )
- 32 Test cases
- 33 Testing schedule
- V Project Issues
- 34 Open Issues
- 35 Off-the-Shelf Solutions
- 35a Ready-Made Products
- 35b Reusable Components
- 35c Products That Can Be Copied
- 36 New Problems
- 36a Effects on the Current Environment....................................................................
- 36b Effects on the Installed Systems..........................................................................
- 36c Potential User Problems
- the New Product 36d Limitations in the Anticipated Implementation Environment That May Inhibit
- 36e Follow-Up Problems
- 37 Tasks
- 37a Project Planning
- 37b Planning of the Development Phases
- 38 Migration to the New Product
- 38a Requirements for Migration to the New Product
- 38b Data That Has to Be Modified or Translated for the New System
- 39 Risks
- 40 Costs
- 41 Waiting Room
- 42 Ideas for Solutions
- 43 Project Retrospective
- VI Glossary
- VII References / Bibliography
- VIII Index
List of Tables
If a document contains a large number of tables, then it is appropriate to include a list of tables at the beginning of the document, following the table of contents. Each table should include a title, and be numbered in a consistent logical fashion. The following list of tables was automatically generated from table captions ( see below), and can be automatically updated by right-clicking on the table below and selecting “Update Field”. This feature is located in the “Captions” section of the “References” tab in MS Word. Note: Remove this instructional paragraph.
Table 1- Sample Table of Survey Dive Activity .......................................................................... 11
The following sample table and figure are only here to initialize the list of figures and list of tables above. They should be removed when real ones are included in the document. ( I.e. delete this entire page when you can. )
Date Participants Activities Notes
Table 1- Sample Table of Survey Dive Activity
Figure 1 - Sample Image of a Survey Dive Boat ( photo by Tony Kiefer )
We want to give immediate and complete response to customers who order our goods over the telephone.
We want to be able to forecast the weather.
2c Measurement
Any reasonable goal must be measurable. This is necessary if you are ever to test whether you have succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. If the project is worthwhile, there must be some solid business reason for doing it. For example, if the goal of the project is
We want to give immediate and complete response to customers who order our goods over the telephone.
you have to ask what advantage that goal brings to the organization. If immediate response will result in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.
It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.
3 The Scope of the Work
This section describes the ( business ) environment in which the product will be used.
3a The Current Situation
Content
This is an analysis of the existing business processes, including the manual and automated processes that might be replaced or changed by the new product. Business analysts might already have done this investigation as part of the business case analysis for the project.
Motivation
If your project intends to make changes to an existing manual or automated system, you need to understand the effect of proposed changes. The study of the current situation provides the basis for understanding the effects of proposed changes and choosing the best alternatives. Knowing what users are doing now can give insight into their views of a proposed new system.
3b The Context of the Work
Content
The work context diagram identifies the work that you need to investigate to be able to build the product. Note that it includes more than the intended product. Unless we understand the work that the product will support, we have little chance of building a product that will fit cleanly into its environment.
The adjacent systems on the context diagram (e.g., Weather Forecasting Service) indicate other subject matter domains (systems, people, and organizations) that need to be understood. The interfaces between the adjacent systems and the work context indicate why we are interested in the adjacent system. In the case of Weather Forecasting Service, we can say that we are interested in the details of when, how, where, who, what, and why it produces the District Weather Forecasts information.
Motivation
To clearly define the boundaries for the study of the work and requirements effort. Without this definition, we have little chance of building a product that will fit seamlessly into its environment.
3c Work Partitioning
Note: Volere talks of dividing up the work according to the different business events to which the business must respond. However each response to a business event is effectively a use-case, so Volere’s list of business events is effectively the same as a use-case diagram and a descriptive list of the associated use-cases.
Content
A list showing all business events to which the work responds. Business events are happenings in the real world that affect the work. They also happen because it is time for the work to do something—for example, produce weekly reports, remind nonpaying customers, check the status of a device, and so on. The response to each event is called a business use case; it represents a discrete partition of work that contributes to the total functionality of the work.
The event list includes the following elements:
● Event name
● Input from adjacent systems (identical with name on context diagram)
● Output to adjacent systems (identical with name on context diagram)
● Brief summary of the business use case (This is optional, but we have found it is a very useful first step in defining the requirements for the business use case—you can think of it as a mini-scenario.)
Motivation
To identify logical chunks of the system that can be used as the basis for discovering detailed requirements. These business events also provide the subsystems that can be used as the basis for managing detailed analysis and design.
Example
Business Event List
Event Name Input and Output Summary
- Weather Station transmits reading
Weather Station Readings (in)
Record the readings as belonging to the weather station.
- Weather Service forecasts weather
District Weather Forecast (in)
Record the forecast.
- Road engineers advise changed roads
Changed Road (in) Record the new or changed road. Check that all appropriate weather stations are attached.
- Road Engineering installs new Weather Station
New Weather Station (in)
Record the weather station and attach it to the appropriate roads.
- Road Engineering changes Weather Station
Changed Weather Station (in)
Record the changes to the weather station.
- Time to test Weather Stations
Failed Weather Station Alert (out)
Determine if any weather stations have not transmitted for two hours, and inform Road Engineering of any failures.
- Truck Depot changes a truck
Truck Change (in) Record the changes to the truck.
- Time to detect icy roads
Road De-icing Schedule (out)
Predict the ice situation for the next two hours. Assign a truck to any roads that will freeze. Issue the schedule.
- Truck treats a road Treated Road (in) Record the road as being in a safe condition for the next three hours. 10 Truck Depot reports problem with truck
Truck Breakdown (in) Amended Gritting Schedule (out)
Reassign available trucks to the previously assigned roads.
- Time to monitor road treatment
Untreated Road Reminder (out)
Check that all scheduled roads have been treated in the assigned time, and issue reminders for any untreated roads.
Considerations
Attempting to list the business events is a way of testing the work context. This activity uncovers uncertainties and misunderstandings about the project and facilitates
thing she has to do is to make sure that all the end-of-the-month tests have been run, and that everyone else is logged off of the system. Then she selects the date range and the specific information she wants included in her reports, selects either the long or short format, and selects a printer. Depending on how busy the month has been, it may take as long as fifteen minutes, during which time no one else can use the system. She only prints one copy on the computer, and then makes all the rest of the copies she needs on the copy machine.
5 Stakeholders
5a The Client
Content
This item gives the name of the client. It is permissible to have several names, but having more than three negates the point.
Motivation
The client has the final say on acceptance of the product, and thus must be satisfied with the product as delivered. You can think of the client as the person who makes the investment in the product. Where the product is being developed for in-house consumption, the roles of the client and the customer are often filled by the same person. If you cannot find a name for your client, then perhaps you should not be building the product.
Considerations
Sometimes, when building a package or a product for external users, the client is the marketing department. In this case, a person from the marketing department must be named as the client.
5b The Customer
Content
The person intended to buy the product. In the case of in-house development, the client and the customer are often the same person. In the case of development of a mass-market product, this section contains a description of the kind of person who is likely to buy the product.
Motivation
The customer is ultimately responsible for deciding whether to buy the product from the client. The correct requirements can be gathered only if you understand the customer and his aspirations when it comes to using your product.
5c Hands On Users of the Product
Content
A list of a special type of stakeholder—the potential users of the product. For each category of user, provide the following information:
● User name/category: Most likely the name of a user group, such as schoolchildren, road engineers, or project managers.
● User role: Summarizes the users’ responsibilities.
● Subject matter experience: Summarizes the users’ knowledge of the business. Rate as novice, journeyman, or master.
● Technological experience: Describes the users’ experience with relevant technology. Rate as novice, journeyman, or master.
● Other user characteristics: Describe any characteristics of the users that have an effect on the requirements and eventual design of the product. For example:
Physical abilities/disabilities
Intellectual abilities/disabilities
Attitude toward job
Attitude toward technology
Education
Linguistic skills
Age group
Gender
Motivation
Users are human beings who interface with the product in some way. Use the characteristics of the users to define the usability requirements for the product. Users are also known as actors.
Examples
Users can come from wide variety of (sometimes unexpected) sources. Consider the possibility of your users being clerical staff, shop workers, managers, highly trained operators, the general public, casual users, passers-by, illiterate people, tradesmen, students, test engineers, foreigners, children, lawyers, remote users, people using the system over the telephone or an Internet connection, emergency workers, and so on.