Regular Project Guidline For Software Engineering

Note: Keep In mind that, you have to state everything inline to your project asides to the definitions
mentioned underneath
Project Report Template

Kombolcha Institute of
Technology
College of Informatics
Department of Software Engineering
This document is prepared by Tilahun Ayalew, Ashenafi Workie, Bihonegn Abebe

and Leul Aynekulu. Its purpose is to help Software Engineering graduate class
students compile their Final Year project report document.
03/04/2022
Cover Page
Kombolcha Institute of Technology

College of Informatics
Department of Software Engineering
We here by Submitted a project in <Title >in partial fulfilment of bachelor’s

Degree in Software Engineering
Submitted to the departments of <department>
Group Members:
No. Name ID Number

1. ……………….. …….
2. ……………….. ……..
3. ……………….. ………
4. ……………….. ………
Advisor’s Name: _______________________ Signature_________________
DD/MM/YYYY
Discriminations
We hereby declare that our project in titled <your title here> is original and not
submitted/Published by any individual/ Organization.
Group members
S.N. Name List ID Number date ----/----/2022 sign:
1.
2.
3.
4.
Advisor’s
Name: Date: ---------/----/2022 Sign:
Acknowledgement
This is optional, although most reports include a brief statement of thanks in recognition of special
assistance and guidance given by individuals, institutions or government bodies.
03/04/2022
Table of contents
The titles of sections, chapters and their principal subdivisions along with the page numbers on
which they appear should be listed in the Table of Contents. Titles should be worded exactly as
they appear in the text of the report. Reports with many subdivisions should use a hierarchical
numbering system for headings and sub-headings (e.g., 3.1). Such a numbering system combined
with the judicious use of upper and lower case, indentations and italics should provide a summary
of the relationships between the sections of the report. The table of contents should be generated
automatically. The following is a recommended content structure.
Table of Contents
Acknowledgement .......................................................................................................................... 5
Table of contents ............................................................................................................................. 6
Lists of Tables, Figures/Illustrations, Plates/Photographs ............................................................ 11
List of Abbreviations, Symbols, Specialized Nomenclature ........................................................ 12
Abstract ......................................................................................................................................... 13
Chapter One: Introduction ............................................................................................................ 14
1.1 Introduction ............................................................................................................................. 14
1.1.1 Background of the organization ..................................................................................... 14
1.1.2 Existing System of the project ....................................................................................... 14
1.1.3 Statement of the problem ............................................................................................... 14
1.1.4 Proposed System ............................................................................................................ 14
1.2 Objective ................................................................................................................................. 15
1.2.1 General Objectives ......................................................................................................... 15
1.2.2 Specific Objectives ......................................................................................................... 15
1.3 Scope and limitation of the project ......................................................................................... 15
1.3.1 Scope .............................................................................................................................. 15
1.3.2 Limitations ..................................................................................................................... 15
1.4 Methodology for the project ................................................................................................... 15
1.4.1 Data collection and fact-finding techniques ................................................................... 15
1.4.2 System analysis and design approach ............................................................................ 16
1.4.3 Technology requirements ............................................................................................... 16
1.5 Feasibility Study ..................................................................................................................... 16
1.5.1 Technical Feasibility ...................................................................................................... 16
1.5.2 Operational Feasibility ................................................................................................... 16
1.5.3 Economic Feasibility ...................................................................................................... 16
1.5.4 Legal Feasibility ............................................................................................................. 16
1.5.5 Political Feasibility......................................................................................................... 16
1.6 Risk assessment strategy ......................................................................................................... 16
1.7 Significance of the project ...................................................................................................... 16
1.7.1 Beneficiary of the project ............................................................................................... 16

1.8 Schedule of the project............................................................................................................ 16
1.9 Project Budget break-down and cost analysis ........................................................................ 17
1.10 Team composition of the project ....................................................................................... 17
Chapter Two System Requirement Specification ......................................................................... 18
2.1 Background (Overview).......................................................................................................... 18
2.1.1 Scope .............................................................................................................................. 19
2.1.2 Purpose ........................................................................................................................... 19
2.1.3 Document Convention.................................................................................................... 19
2.1.4 Intended Audience and Suggested Readings ................................................................. 20
2.1.5 List of Acronyms, Abbreviations and Definitions ......................................................... 20
2.2 Overall Description of Software Requirements ...................................................................... 20
2.2.1 Product Perspectives ...................................................................................................... 20
2.2.2 User characteristics ........................................................................................................ 21
2.3 General Constraints ................................................................................................................. 21
2.3.1 Software constraints ....................................................................................................... 21
2.3.2 Hardware Constraints ..................................................................................................... 21
2.3.3 Assumptions and Dependencies ..................................................................................... 21
2.3.4 User Documentations ..................................................................................................... 21
2.4 Specific Requirements ............................................................................................................ 22
2.4.1 User requirements .......................................................................................................... 22
2.4.2 Functional Requirements................................................................................................ 22
2.4.3 Non-Functional Requirements ....................................................................................... 22
2.5 External Interface requirements .............................................................................................. 22
2.5.1 User Interfaces................................................................................................................ 22
2.5.2 Hardware Interfaces ....................................................................................................... 22
2.5.3 Software Interfaces ......................................................................................................... 23
2.5.4 Communication Interfaces ............................................................................................. 23
2.6 System requirements Modeling .............................................................................................. 23
2.7 Essential use case Diagrams ................................................................................................... 23
Chapter Three Requirement Analysis Modeling .......................................................................... 24

3.1 Overview of Analysis Model .................................................................................................. 24
3.2 System use case Diagram........................................................................................................ 24
3.2.1 Scenario .......................................................................................................................... 25
3.2.2 Use case Model .............................................................................................................. 25
3.2.3 Use case Description ...................................................................................................... 25
3.3 Sequence Diagram .................................................................................................................. 25
3.4 Activity Diagrams ................................................................................................................... 26
3.5 Communication diagram if any .............................................................................................. 26
3.6 Conceptual class diagram ....................................................................................................... 26
Chapter Four System Design ........................................................................................................ 27
4.1 Overview ................................................................................................................................. 27
4.1.1 Design considerations and Purposes .............................................................................. 27
4.1.2 Design goals ................................................................................................................... 28
4.1.3 Design guidance and Issues............................................................................................ 28
4.1.1.1 Performance ................................................................................................................ 29
4.1.1.2 Dependability.............................................................................................................. 29
4.1.1.3 Maintenance................................................................................................................ 29
4.2 Proposed system architecture .................................................................................................. 30
4.2.1 System process ............................................................................................................... 30
4.2.2 Subsystem decomposition .............................................................................................. 30
4.2.3 Hardware / software mapping ........................................................................................ 30
4.2.4 Persistent data management ........................................................................................... 30
4.3 Design Control ........................................................................................................................ 30
4.4 Low-level Design Model ........................................................................................................ 31
4.4.1 Class Diagram ................................................................................................................ 31
4.4.2 Object Model .................................................................................................................. 31
4.4.3 State chart Diagram ........................................................................................................ 31
4.4.4 Component’s diagram .................................................................................................... 31
4.4.5 Deployment Diagram ..................................................................................................... 32
4.5 Database Design...................................................................................................................... 32

4.5.1 Data Dictionary .............................................................................................................. 32
4.5.2 Metadata ......................................................................................................................... 32
4.6 Boundary condition and Access control ................................................................................. 32
4.6.1 Access controlling .......................................................................................................... 32
Chapter Five Implementation ....................................................................................................... 33
5.1 Overview ................................................................................................................................. 33
5.2 Coding ..................................................................................................................................... 33
5.2.1 Characteristics of Good project development ................................................................ 33
5.3 Software Documentation ........................................................................................................ 34
5.4 Algorithm and special code .................................................................................................... 34
5.5 System Screenshot (only important one) ................................................................................ 34
Chapter Six System Testing .......................................................................................................... 35
6.1 Overview ................................................................................................................................. 35
6.1.1 Purpose ........................................................................................................................... 35
6.1.2 Scope .............................................................................................................................. 36
6.1.3 Design Test cases ........................................................................................................... 36
6.2 Program Analysis Tools .......................................................................................................... 36
6.2.1 Load Performance Testing ............................................................................................. 36
6.3 Test plan report ....................................................................................................................... 37
Chapter 7: Conclusion and Recommendation............................................................................... 37
7.1 Conclusions ............................................................................................................................. 37
7.2 Recommendation .................................................................................................................... 37
References ..................................................................................................................................... 38
Appendices .................................................................................................................................... 39
Lists of Tables, Figures/Illustrations, Plates/Photographs
These lists consist of the exact titles (including numbering) of all tables, figures and plates that
appear in the report. All tables, figures and plates should be numbered consecutively throughout
the text.
List of Abbreviations, Symbols, Specialized Nomenclature
This list is optional, depending on the subject of the report. All scientific symbols and
nomenclature should follow the standard SI-system.
Abstract
An abstract in both Amharic and English are required. The English version must include the title
written in English for a report written in Amharic, and vice versa. The abstract is a summary of
the entire report. It should briefly outline the research problems addressed by the report, the
findings, and the significance of the work in the context of the field of study. The abstract should
not exceed one typewritten single-spaced page of text (c. 300-400 words) with the font size of 12
points. Abstracts in English should be in italic.
Chapter One: Introduction

1.1 Introduction
This chapter is concerned with similar concerns to the abstract and should provide an overview of
the report with more detail. The methodology should be stated and describe here as different
section. The contribution of the student should be stated precisely and in detail. The structure of
the report should be given detailing where each chapter fits within the overall and what each
contributes; it may be useful to provide a diagram showing dependencies and relationships
between chapters.
Chapter 1: Is often the last chapter to be written, and to be checked carefully before submission.
It is a key chapter, which the external examiner may read when making his assessment as illustrated
below.
2
1.1.1 Background of the organization
This sub topic is concerned the selected organization’s target goal in line with the proposed project
under development. More specifically, it addresses the point of organizational vision, mission and
core values in associated to the project.
1.1.2 Existing System of the project
Under this subtitle students should mention what existing system is, how it is functioning, is that
manual? Automated? Semi-automated? Or considered as continuing as it is, has a tendency to do
projects and opportunities? Or even proceeded as legacy system. So that students must mention
the details about the existing system merits and demerits in comparation to the proposed system.
1.1.3 Statement of the problem
Under this section, students clearly elaborate the existed problems in detail. Even students must
mention why the problem raised. At the same time, the proposed system should entails what are
the positive and negative consequences in the way forwarded to solving the mentioned problem.
The existed problem must be explained in a manner to be counted whether it is properly solved or
not. Keep in mind that each problem must be stated not listed.
1.1.4 Proposed System
Once the problem mentioned and the existing system identified, here students are required to
proposed the alternative solutions against or in complementary to the existing system.
1.2 Objective
1.2.1 General Objectives
The general objective is the overall objective while properly developed and deployed the
project.
1.2.2 Specific Objectives
Under this section, students must list the questions to be answered by the project in parallel to the
already stated problems. In fact, here students must solve the entire aforementioned problem in the
statement of the problems with the proposed solutions. Since stated problems are counted, the
specific objectives are also counted and formatted in a form to be check listed.
1.3 Scope and limitation of the project
1.3.1 Scope
The scope of the project precisely states the mandate areas where the project is deployed, the
system requirements satisfied under this project or not to be covered. Please states the boundary
of the project. in what level you will address the projects domain.
1.3.2 Limitations
The limitation is all about the underdevelopment systems compatibility, portability,
maintainability and other related limitations as viewed from users and technological perspectives.
The system functionality that you didn't address in this version of project due to constraints is said
to be Limitation. do not mix limitation with
1.4 Methodology for the project
The project methodology entails, the software and hardware tools used in realizing the proposed
project and the rationales behind each selection. It also required mentioning the project
development approaches, paradigms in detail reasoning to help fact-finding techniques.
1.4.1 Data collection and fact-finding techniques
In this section member of the project explains the extent source of data for the proposed project. It
also illustrates the requirement elicitation approaches through which method of data collection
they can found the exact data /Source of Information including the type of Information source
either from primarily, secondary and from others.
1.4.2 System analysis and design approach

1.4.3 Technology requirements
Software requirements
Hardware requirements
1.5 Feasibility Study
Here, students must explain the proposed systems technical, operational, economic, legal, and
political feasibility. It is clearly stated the improvements now and in the long run in all perspectives.
1.5.1 Technical Feasibility
1.5.2 Operational Feasibility
1.5.3 Economic Feasibility
1.5.4 Legal Feasibility
1.5.5 Political Feasibility
1.6 Risk assessment strategy
Students should mention what are the possibly expected risks in developing the proposed project.
This is evaluated, in line with completing the project within the scheduled time. In case external
barrios are suggested, list out the recommended contingency management alternatives.
1.7 Significance of the project
Highlights the value that the project outcomes may provide in the field or real-world practice. This
section highlights the positive contribution of completing the study or project
1.7.1 Beneficiary of the project
Detail explanation the beneficiary of the project
For Clients (project owner)
For System users
For developer (for you)
1.8 Schedule of the project
using the already available sheduling tools such as giant chart and others, proporely, scheduled
for each project components.
1.9 Project Budget break-down and cost analysis

The budget of the project is clearly explained. Under this section students should do some
preliminary investigation what hardware and software tools used to do the project and metric those
all in cash. Furthermore, the budget analysis encompasses the situations leading cost not only for
the project developers but also for the deployment Organizations including all other contingency
management plan.
1.10 Team composition of the project
Under this section, students must show who is a focal person identified componets of the project
as per the scheduling guideline. But make sure that each member of the project underconstruction
must know in depth abou the entire projects component and contribute for the entire project’s
quality perimetrs by providing multiple alternatives and choosing the rationale among alternative
aspects.
Chapter Two System Requirement Specification

2.1 Background (Overview)
This chapter should first present the background to the area of investigation and establishing the
context of the problem. Understanding the problem domain in detail should be the first step and it
is a foundation for the rest of the project work. Often this background consists of a survey and
review of literature/documents associated with the problem context. Sometimes on site observation
might be necessary.
The literature should not simply be represented but critically analyzed by the student. All sources
used should be precisely cited in the text, i.e. in a way that enables the reader to access the source.
If material is copied directly then it should be placed in quotes and the reference given quoted. In
general, copying of this type should be avoided. If a diagram is copied then the caption should give
the reference.
The major concern of this chapter is establishing the detailed requirements specification for the
work. The nature of these requirements depends on the type of project being investigated. These
requirements could be obtained from a number of sources (many of which may have been
discussed in detail in the background). The chapter should indicate the ways in which the
requirements have been obtained. Once obtained the requirements should be expressed, prioritized
and detailed in an appropriate form. As much as possible the requirements should be measurable
and quantified so that it can be determined if they have been met.
Requirements should be classified as functional and non-functional requirements. You should
follow and apply Software Engineering practices for user requirements elicitation and engineering.
Please refer your Software Engineering course on requirements elicitation and engineering.
Details are explained below.
3
3.1
2
2.1
2.1.1 Scope
Show the exact part of project planning that involves determining and documenting a list of
specific project goals, deliverables, tasks, cost and deadlines. The Project Scope pertains to the
work necessary to deliver a product
2.1.2 Purpose
Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem
It is where you state the purpose of the project in line with the requirements specification.
2.1.3 Document Convention
Describe any standards or typographical conventions that were followed when writing the SRS,
such as fonts or highlighting that have special significance. For example, state whether priorities
for higher-level requirements are assumed to be inherited by detailed requirements, or whether
every requirement statement is to have its own priority. Use your report convention
Indicators Most common and recommended

Alignment Justified
Margin Left=3cm, right=2.5, top=2.5, bottm=2.5
Title font size /heading 1 e.g 16pt ,bold
Chapter One
Sub Title font size /heading 2 e.g 14pt
1.1Introduction
Sub Title font size /heading 3 e.g 12pt
1.1.1 Introduction
Whole document / Normal text Font size 12

Font style Regular
Font type Time New Roman
Page Color White
Language English
Line between 1.5
Correction with fluid Not allowed
Typing machine Computer
Crossing out words Not allowed
Printing quality Laser or later quality
Font color Black
2.1.4 Intended Audience and Suggested Readings

Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most pertinent
to each reader type
2.1.5 List of Acronyms, Abbreviations and Definitions

Describe all used abbreviated terms, symbols, and definition wise aspects in your documentation.
2.2 Overall Description of Software Requirements
Put the rationale behind requirement specifications in relation to your working environment. So as
to assure, your competitive advantage in all cost, quality and timing dimensionality, your
requirement specification must be tightly elaborated.
2.2.1 Product Perspectives

Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the SRS defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. A simple diagram that shows the major components of the overall
system, subsystem interconnections, and external interfaces can be helpful.>2.2.2. Product
Features/Functions
List out and elaborate the required functional requirements from the users’ perspectives.
2.2.2 User characteristics
Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent characteristics
of each user class. Certain requirements may pertain only to certain user classes. Distinguish the
most important user classes for this product from those who are less important to satisfy.
2.3 General Constraints

Here you have to mention the overall hardware and software Constraints while developing and
deploying the proposed project.
2.3.1 Software constraints

Describe the Operating Environment that the product is intended to run on. Specify Design and
Implementation Constraints. Describe any issues that will limit the options available to the
developers. These might include corporate or regulatory policies, hardware limitations and so on.
2.3.2 Hardware Constraints

It is optional that, if you propose a new and cross discipline project you may fail comfort in
accessing required hardware apparatus. But it does not mean a problem in the long run as far as
the project is feasible.
2.3.3 Assumptions and Dependencies

List any assumptions that could affect the requirements stated in this SRS. Third party or
commercial components that you plan to use or issues around the development. These requirements
are affected if these assumptions are not shared, are incorrect or change.
2.3.4 User Documentations
You describe how you are going to distribute your documentation to your customer and product
users in a part.
2.4 Specific Requirements

In order for your development team to meet the requirements properly, we MUST include as much
detail as possible. This can feel overwhelming but becomes easier as you break down your
requirements into categories.
2.4.1 User requirements
Describes the business needs for what users require from the system. User Requirements
Specifications are written early in the validation process, typically before the system is created.
They are written by the system owner and end-users, with input from Quality Assurance.
2.4.2 Functional Requirements
Itemize the detailed functional requirements associated with this feature. These are the software
capabilities that must be present in order for the user to carry out the services provided by the
feature, or to execute the use case. Include how the product should respond to anticipated error
conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable,
and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet
available
Indicate what a software system must do and how it must function; they are product features that
focus on user needs. Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind
2.4.3 Non-Functional Requirements
States that a requirement that specifies criteria that can be used to judge the operation of a
system, rather than specific behaviors. These includes performance, safety, security etc.
2.5 External Interface requirements
2.5.1 User Interfaces
Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any graphical user Interfaces standards or product family
style guides that are to be followed.
2.5.2 Hardware Interfaces
Instead, describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system.
2.5.3 Software Interfaces

Are the connections between this product and other specific software components (name and
version), including databases, operating systems, tools, libraries, and integrated commercial
components.
2.5.4 Communication Interfaces
Describe in this part the requirements associated with any communications functions required by
this product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on.
2.6 System requirements Modeling
It is all about a document or set of documentation that describes the features and behavior of a
system or software application. It is all about a technical representation of the system. It acts as
a link between system description and design model. In Analysis Modelling, information,
behavior, and functions of the system are defined and translated into the architecture, component,
and interface level design in the design modeling.
2.7 Essential use case Diagrams
You must entail a structured narrative, expressed in. the language of the application domain
and of users, comprising a simplified, generalized, abstract, technology free and implementation
independent description of one task or interaction that is complete, meaningful, and well defined
You have to describe the functionality provided by a system in terms of actors, their goals
represented as use cases, and any dependencies among those use cases. Here you have also
elaborate the use case descriptions as represented in the system use case diagram without
compromising their dependencies and their definiteness.
Chapter Three Requirement Analysis Modeling

3.1 Overview of Analysis Model
Requirements analysis is an elaboration of the basic requirements established during requirement
elicitation. This is the first technical representation of the proposed system using a series of
requirements modeling approaches like,
Once you identify your system requirements in chapter 2, you should elaborate it using the above
requirements modeling approaches. This chapter is a basis for the design phase.
A model captures aspects important for some application while omitting (or abstracting) the rest.
A model in the context of software development can be graphical, textual, mathematical, or
program code-based. Models are very useful in documenting the design and analysis results.
Models also facilitate the analysis and design procedures themselves. Graphical models are very
popular because they are easy to understand and construct.
Rationales behind need for a model: An important reason behind constructing a model is that it
helps manage complexity. Once models of a system have been constructed, these can be used for
a variety of purposes during software development, including Analysis, Specification, Code
generation, Design, Visualize and understand the problem and the working of a system and
Testing,
3.2System use case Diagram
You have to describe the functionality provided by a system in terms of actors, their goals
represented as use cases, and any dependencies among those use cases. Here you have also
elaborate the use case descriptions as represented in the system use case diagram without
compromising their dependencies and their definiteness.
3.2.1 Scenario
Describes the situation in which a limited consideration for each and suggested requirements are
failed to meet customers’ or systems requirements. So as consider alternative approaches, a list of
possibly considered situations are predetermined with a list of possible solutions.
3.2.2 Use case Model
The use case model for any system consists of a set of “use cases”. Intuitively, use cases
represent the different ways in which a system can be used by the users. A simple way to find all
the use cases of a system is to ask the question: “What the users can do using the system?”
3.2.3 Use case Description
Each ellipse on the use case diagram should be accompanied by a text description. The text
description should define the details of the interaction between the user and the computer and
other aspects of the use case. It should include all the behavior associated with the use case in
terms of the mainline sequence, different variations to the normal behavior, the system responses
associated with the use case, the exceptional conditions that may occur in the behavior, etc. The
behavior description is often written in a conversational style describing the interactions between
the actor and the system. The text description may be informal, but some structuring is
recommended.
3.3 Sequence Diagram

Here shows object interactions arranged in time sequence in the field of software engineering. It
depicts the objects involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of scenario.
A sequence diagram shows interaction among objects as a two-dimensional chart. The chart is read
from top to bottom. The objects participating in the interaction are shown at the top of the chart as
boxes attached to a vertical dashed line. Inside the box, the name of the object is written with a
colon separating it from the name of the class and both the name of the object and the class are
underlined.
3.4Activity Diagrams
Visually presents a series of actions or flow of control in a system similar to a flowchart or a data
flow diagram. Activity diagrams are often used in business process modeling. They can also
describe the steps in a use case diagram. Activities modeled can be sequential and concurrent.
3.5Communication diagram if any

A Communication diagram is a diagram that shows the interactions between elements at run-time
in much the same manner as a Sequence diagram. However, Communication diagrams are used to
visualize inter-object relationships, while Sequence diagrams are more effective at visualizing
processing over time.
Communication diagrams employ ordered, labeled associations to illustrate processing.

Numbering is important to indicate the order and nesting of processing. A numbering scheme
could be:1 ,1.1,1.1.1 ,1.1.2,1.2, and so on.
3.6 Conceptual class diagram

Students may depict high-level diagram that helps to analyze the basic components of class
diagram which furtherly explained in chapter four
Chapter Four System Design

4.1 Overview
The design is concerned with presenting the design of the artifact developed and justifying how it
should meet the identified requirements. It is likely to consist of three parts:
1. How and why the design has been carried out the approach and notation used, etc.;
2. The conceptual level design;
3. Communication and description of the design.

As appropriate, alternatives considered may be discussed with justification for the approach taken.
The design should be expressed and detailed in a suitable form. In addition, this chapter should
include database design and user interface design in detail. The details are as illustrated below-
4.1.1 Design considerations and Purposes
Design is where customer requirements, business needs, and technical considerations all come
together in the formulation of a product or system
●The design model provides detail about the software data structures, architecture, interfaces, and
components
● The design model can be assessed for quality and be improved before code is generated and
tests are conducted.
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
Architectural Design: The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with each other.
At this level, the designers get the idea of proposed solution domain.
 High-level Design: The high-level design breaks the ‘single entity-multiple component’
concept of architectural design into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design focuses on how the system
along with all of its components can be implemented in forms of modules. It recognizes modular
structure of each sub-system and their relation and interaction among each other.
 Detailed Design: Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules and
their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules.
4.1.2 Design goals

The design must implement all of the explicit requirements contained in the analysis model. It
must also accommodate all of the implicit requirements desired by the customer. The design must
be a readable and understandable guide for those who generate code, and for those who test and
support the software. The design should provide a complete picture of the software, addressing the
data, functional, and behavioural domains from an implementation perspective.
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation. It describes how well designed the
proposed system without compromising the end users’ requirements, the potential legal,
economical, operational feasibilities and other design parameters. More specifically, the cohesion
and coupling balancing principles are compulsory towards improved software development.
Having the above in mind, your design must encompasses: I) Avoid ‘tunnel vision, II)Be traceable
back to analysis, III)Not reinvent the wheel, “Minimize the intellectual distance” between the
problem and the solution, IV)Exhibit uniformity and integration (look like the work of a single
designer), V)Accommodate change , VI)Degrade gently, VII)Be assessed for quality as it is being
created, not after the fact, VIII)Not miss the forest (not focus too much on minutiae), IX)
Recognize that design is not coding, coding is not design
4.1.3 Design guidance and Issues

Debugging is often carried out by programmers based on their ingenuity. The following are some
general guidelines for effective debugging:
 Many times debugging requires a thorough understanding of the program design. Trying to
debug based on a partial understanding of the system design and implementation may require an
inordinate amount of effort to be put into debugging even simple problems.
 Debugging may sometimes even require full redesign of the system. In such cases, a common
mistake that novice programmers often make is attempting not to fix the error
but its symptoms.
 One must be beware of the possibility that an error correction may introduce new errors.
Therefore, after every round of error-fixing, regression testing must be carried out.
4.1.1.1 Performance
Data management takes into account the system requirements concerning performance and space.
From an understanding of the data requirements and constraints, one lays out a design for the
objects and their operations. You have to realize by:
 Identify the data, data structures, and relationships among them
 Design services to manage the data structures and relationships
 Find tools, such as database management systems, to implement some of the data
management tasks
 Design classes and class hierarchies to oversee the data management functions
4.1.1.2 Dependability
It is desirable that programs can be developed in the language as a collection of separately
compiled modules, with appropriate mechanisms for ensuring self-consistency between these
modules. In contrast to associations are structural relationships, dependencies are non-structural
relationships. In order for objects to “know each other”, they must be visible. These is associated
with Framework, Third Party Libraries, Database, File System, Web Services, System Resources
(Clock), Configuration, The new Keyword, Static methods….
4.1.1.3 Maintenance
Becoming an important activity of a large number of software organizations. This is not surprise,
given the rate of hardware obsolescence, the immortality of a software product per users, and the
demand of the user community to see the existing software products run on newer platforms, run
in newer environments, and/or with enhanced features. When the hardware platform is changed,
and a software product performs some low-level functions, maintenance is necessary. In addition,
whenever the support environment of a software product changes, the software product requires
rework to cope up with the newer interface.
4.2 Proposed system architecture
Describes the skeleton that showing all abstractions and dependencies within the entire system in
a form elegant, standardized, and expressive towards a specified organizational goal. Furthermore,
it includes improved features as per the prescribed software requirements specifications.
4.2.1 System process
Includes all activities, which help the transformation of requirement specification into
implementation. Requirement specifications specify all functional and non-functional expectations
from the software. These requirement specifications come in the shape of human readable and
understandable documents, to which a computer has nothing to do.
4.2.2 Subsystem decomposition
Breakdown all embedded subsystems and rationales behind their emerging in relation to a standard
system design guideline. Just a “cross between” a package and a class and realizes one or more
interfaces which define its behavior.
4.2.3 Hardware / software mapping
“Clients should not be forced to depend on methods that they do not use.” [R. Martin]. When we
bundle functions for different clients into one interface/class, we create unnecessary coupling
among the clients. When one client causes the interface to change, all other clients are forced to
recompile. So that, your System is by far better while designed considering the existing and
upcoming hardware apparatuses. In addition, the Interface Segregation Principle states that
Clients should not be forced to depend on methods they do not use.
4.2.4 Persistent data management
Describes consistency reservation elements incorporated/used to ensure persistency of your project
in situations where internal/external factors required challenging. So as to come up with
persistency of used data and generated data, alternative backup and recovery techniques,
technologies suggested/planned must be mentioned here.
4.3 Design Control
The design process must be properly controlled, this includes controlling coding also. This
requirement means that a good configuration control system must be in place.
 Design inputs must be verified as adequate.

 Design must be verified.
 Design output must be of required quality.
 Design changes must be controlled.
4.4 Low-level Design Model

4.4.1 Class Diagram
A class diagram describes the static structure of a system. It shows how a system is structured
rather than how it behaves. The static structure of a system comprises of a number of class
diagrams and their dependencies. The main constituents of a class diagram are classes and their
relationships: generalization, aggregation, association, and various kinds of dependencies.
4.4.2 Object Model
Object oriented design model works around the entities and their characteristics instead of
functions involved in the software system. This design strategy focuses on entities and its
characteristics. The whole concept of software solution revolves around the engaged entities.
4.4.3 State chart Diagram

A state chart diagram is normally used to model how the state of an object changes in its lifetime.
State chart diagrams are good at describing how the behavior of an object changes across several
use case executions. However, if we are interested in modeling some behavior that involves several
objects collaborating with each other, state chart diagram is not appropriate. State chart diagrams
are based on the finite state machine (FSM) formalism.
4.4.4 Component’s diagram

Show analysis classes represent conceptual things, which can perform behavior.
In design, analysis classes evolve into a number of different kinds of design elements: including
 Classes, to represent a set of rather fine-grained responsibilities;
 Subsystems, to represent a set of coarse-grained responsibilities, perhaps composed of a

further set of subsystems, but ultimately a set of classes;
 Active classes, to represent threads of control in the system;
 Interfaces, to represent abstract declarations of responsibilities provided by a class or
subsystem.
4.4.5 Deployment Diagram
Deployment diagrams showing the nodes and allocation of processes and components.
Commentary on the networking.
4.5 Database Design
Describes the physical representation of Entities/objects and attributes with their identifying
granularities. A more detail representation is required after you realize the project. It ensures back
end tools, incorporated data items, and the way to access to stored data.
4.5.1 Data Dictionary
A Data Dictionary is a collection of names, definitions, and attributes about data elements that are
being used or captured in a database, information system, or part of a research project.A data
dictionary lists all data items appearing in the DFD model of a system. The data items
listed include all data flows and the contents of all data stores appearing on the DFDs in the DFD
model of a system. A data dictionary lists the purpose of all data items and the definition of all
composite data items in terms of their component data items.
4.5.2 Metadata
Metadata describes about data. It is ‘data about data’. It has information about how and when, by
whom a certain data was collected and the data format. It is essential to understand information
that is stored in data warehouses and xml-based web applications.
4.6 Boundary condition and Access control
Describe the extent to which the proposed project must exhibit the quality attributes of a system
under construction including modifiability, exchangeability, reusability, extensibility and
maintainability.
4.6.1 Access controlling

Describes patterns that ‘guard and control access to services or components’, which we can again
recognize as a form of structural grouping in relation to your project Integrity.
Chapter Five Implementation

5.1 Overview
Put a quick overview about implementation
5.2 Coding
The objective of the coding phase is to transform the design of a system into code in a high-level
language and then to unit test this code. The programmers adhere to standard and well-defined
style of coding which they call their coding standard. The main advantages of adhering to a
standard style of coding are as follows
 A coding standard gives uniform appearances to the code written by different engineers
 It facilitates code of understanding.
 Promotes good programming practices.
5.2.1 Characteristics of Good project development
Preliminary characterize towards coding covers the points of:
Readability: A good high-level language will allow programs to be written in some ways that
resemble a quite-English description of the underlying algorithms. If care is taken, the coding may
be done in a way that is essentially self-documenting.
 Portability: High-level languages, being essentially machine independent, should be able
to develop portable software.
 Generality: Most high-level languages allow the writing of a wide variety of programs,
thus relieving the programmer of the need to become expert in many diverse languages.
 Brevity: Language should have the ability to implement the algorithm with less amount
of code. Programs expressed in high-level languages are often considerably shorter than
their low-level equivalents.
 Error checking: Being human, a programmer is likely to make many mistakes in the
development of a computer program. Many high-level languages enforce a great deal of error
checking both at compile-time and at run-time.
 Cost: The ultimate cost of a programming language is a function of many of its
characteristics.
 Familiar notation: A language should have familiar notation, so it can be understood by
most of the programmers.
 Quick translation: It should admit quick translation.
 Efficiency: It should permit the generation of efficient object code.
 Modularity: It is desirable that programs can be developed in the language as a
collection of separately compiled modules, with appropriate mechanisms for ensuring self-
consistency between these modules.
 Widely available: Language should be widely available and it should be possible to
provide translators for all the major machines and for all the major operating systems.
5.3 Software Documentation
When various kinds of software products are developed then not only the executable files and the
source code are developed but also various kinds of documents such as users’ manual, software
requirements specification (SRS) documents, design documents, test documents, installation
manual, etc are also developed as part of any software engineering process. All these documents
are a vital part of good software development practice. Your documentation must prepare as of
internal documentation and External documentation.
5.4 Algorithm and special code
Put only algorithms, or mercy codes that you solve the problems in your projects. No need to
present ordinary codes instead selective algorithm is required. If those code are a many more, you
can present under Appendix sections at end.
5.5 System Screenshot (only important one)
Put some screenshot that your project solves. So no need to screenshot of ordinary webpages rather
only selective pages to be presented here.
Chapter Six System Testing

6.1 Overview
Testing a program consists of providing the program with a set of test inputs (or test cases) and
observing if the program behaves as expected. If the program fails to behave as expected, then
the conditions under which failure occurs are noted for later debugging and correction. Some
commonly used terms associated with testing are:
 Failure: This is a manifestation of an error (or defect or bug). However, the mere presence of
an error may not necessarily lead to a failure.
 Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state
of the system at which the data is input, and O is the expected output of the system.
 Test suite: This is the set of all test cases with which a given software product is to be
tested.
6.1.1 Purpose
The aim of the testing process is to identify all defects existing in a software product. However,
for most practical systems, even after satisfactorily carrying out the testing phase, it is not
possible to guarantee that the software is error free. This is because of the fact that the input data
domain of most software products is very large. It is not practical to test the software
exhaustively with respect to each value that the input data may assume. Even with this practical
limitation of the testing process, the importance of testing should not be underestimated. It must
be remembered that testing does expose many defects existing in a software product. Thus
testing provides a practical way of reducing defects in a system and increasing the users’
confidence in a developed system.
6.1.2 Scope
Clarify the point to be covered while testing and make sure to ensure effective testing over
exhaustive testing. Keep in mind that, the testing tool used must be mentioned and rationalized
from different perspectives.
6.1.3 Design Test cases
Exhaustive testing of almost any non-trivial system is impractical due to the fact that the domain
of input data values to most practical software systems is either extremely large or infinite.
Therefore, we must design an optional test suite that is of reasonable size and can uncover as
many errors existing in the system as possible. Actually, if test cases are selected randomly,
many of these randomly selected test cases do not contribute to the significance of the test suite,
i.e. they do not detect any additional defects not already being detected by other test cases in the
suite. Thus, the number of random test cases in a test suite is, in general, not an indication of the
effectiveness of the testing. In other words, testing a system using a large collection of test cases
that are selected at random does not guarantee that all (or even most) of the errors in the system
will be uncovered.
6.2 Program Analysis Tools
A program analysis tool means an automated tool that takes the source code or the executable
code of a program as input and produces reports regarding several important characteristics of
the program, such as its size, complexity, adequacy of commenting, adherence to programming
standards, etc. This can be realized and classify these into two broad categories of program analysis
tools: Static Analysis tools and Dynamic Analysis tools
6.2.1 Load Performance Testing
Load Performance testing is carried out to check whether the system needs the non-functional
requirements identified in the SRS document. There are several types of performance testing.
Among of them nine types are discussed below. The types of performance testing to be carried
out on a system depend on the different non-functional requirements of the system documented in
the SRS document. All load performance tests can be considered as black-box tests including
Stress testing, Volume testing, Configuration testing, Compatibility testing, Regression testing,
Recovery testing, Maintenance testing, Documentation testing and Usability testing
6.3 Test plan report
Chapter 7: Conclusion and Recommendation
7.1 Conclusions
This chapter should present conclusions about the investigation and outline further work. This
chapter should not be left until the end of the project period. Valuable ideas should be collected
throughout the project and added to a chapter outline. The chapter should re-outline what has been
done in the investigation, and been shown in the report. The lessons learned from the overall
investigation should be presented with appropriate examples.
The evaluation together with new ideas should naturally lead to further work that would “improve”
the work in some sense. The further work section should be substantial in that this is an important
part of a scientific investigation. Often the depth of further work is a good indication of how well
aware the student is of the topic of investigation.
7.2 Recommendation
Recommendations are arguably the most important part of the analysis phase—this is where you'll
suggest specific interventions or strategies to address the issues and constraints identified in the
assessment.
References
Any report, which makes use of other works, either in direct quotation or by reference, must contain
references listing all of these sources. Only works directly cited or quoted in the text should be
included in the references and properly cited.
Appendix A: Special information collected from
Appendix B: Algorithms
….
Appendix D: other
Appendices
This section is optional and will depend on the individual report content. It contains supplementary
illustrative material, original data, and quotations too long for inclusion and not immediately
essential to an understanding of the subject. This section may be divided into sections as
Appendices A, B, C, etc. Any figures or tables included in the appendix should be numbered and
captioned as for all text tables and figures.
Note:
The internal organization of the report is the responsibility of the Candidate in consultation with
his/her supervisor(s). The organization will partly depend on the field of study, but the
responsibility is on the student to provide a systematic and well-organized report. Overall, the font
of the main text should be specified on the guideline. In addition, candidate should put a header
for each page, which is the title of the chapter concerned.

Regular Project Guidline For Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Regular Project Guidline For Software Engineering

Uploaded by

Copyright:

Available Formats

Note: Keep In mind that, you have to state everything inline to your project asides to the definitions

Project Report Template

This document is prepared by Tilahun Ayalew, Ashenafi Workie, Bihonegn Abebe

Kombolcha Institute of Technology

We here by Submitted a project in <Title >in partial fulfilment of bachelor’s

No. Name ID Number

Advisor’s Name: _______________________ Signature_________________

1.7.1 Beneficiary of the project ............................................................................................... 16

Chapter Three Requirement Analysis Modeling .......................................................................... 24

4.5 Database Design...................................................................................................................... 32

Lists of Tables, Figures/Illustrations, Plates/Photographs

List of Abbreviations, Symbols, Specialized Nomenclature

Chapter One: Introduction

1.4.2 System analysis and design approach

1.9 Project Budget break-down and cost analysis

Chapter Two System Requirement Specification

Indicators Most common and recommended

Whole document / Normal text Font size 12

2.1.4 Intended Audience and Suggested Readings

2.1.5 List of Acronyms, Abbreviations and Definitions

2.2.1 Product Perspectives

2.3 General Constraints

2.3.1 Software constraints

2.3.2 Hardware Constraints

2.3.3 Assumptions and Dependencies

2.4 Specific Requirements

2.5.3 Software Interfaces

Chapter Three Requirement Analysis Modeling

3.3 Sequence Diagram

3.5Communication diagram if any

Communication diagrams employ ordered, labeled associations to illustrate processing.

3.6 Conceptual class diagram

Chapter Four System Design

2. The conceptual level design;

3. Communication and description of the design.

4.1.2 Design goals

4.1.3 Design guidance and Issues

 Design inputs must be verified as adequate.

4.4 Low-level Design Model

4.4.3 State chart Diagram

4.4.4 Component’s diagram

 Subsystems, to represent a set of coarse-grained responsibilities, perhaps composed of a

4.6.1 Access controlling

Chapter Five Implementation

Chapter Six System Testing

6.3 Test plan report

Chapter 7: Conclusion and Recommendation

You might also like

Advisor’s Name: _______ Signature_