Software Engineering

Description

Course Overview

Software Engineering is about the orderly, timely and cost effective production of quality software that is not only useful but also usable. As such software engineering not only focuses on technology but also on the non-technical issues that are faced by software Engineers during the production of software. Research in this discipline shows that most of the software projects that fail because of reasons other than technology, therefore a Software Engineering degree should address these areas so that our graduates are able to address issues when they encounter them in their professional careers
Software Engineers are in great demand in this economy due to the expensive nature of imported software. The cost of software will come down tremendously when that software is produced by locally trained software engineers.

UNIVERSITIES IN BENIN REPUBLIC…

APPLY NOW

Course objectives

The aim of the programme is to produce graduates that are competent in the production of software and to be able to design and implement suitable software applications on a wide scale. The specific objectives are produce graduates that have:

•  Acquired both Theoretical and Practical skills in Software Engineering to be productive in society;
•  Acquired adequate knowledge to pursue postgraduate studies;
•  A basis for further research and solutions to Software Engineering problems that are customized for this region.

Admission Requirement

Any applicant who meets the minimum entry requirements for admission into the University may be granted admission, the requirements are :

• An A’ Level Certificate (a Degree, HND or PGD) with 2:2, Lower credit, or Pass respectively and above.
• Transcript of the A’Level result.
• Copy of International Passport data page.
• A copy of CV.

 

REGISTRATION PROCESS

To register for any of the available courses take the following steps

• Click on courses on the menu bar or apply now button to pick a course
• After selecting the course, click apply now to add to cart
• View the cart to fill the application form
• Submit the form to go to the payment page
• Complete the payment form and select method of payment and submit.
• You will receive an email letting you know of your registration and your application status
• You will be contacted by one of our admission team member to guide you on the admission.
• After making the payment of application fee admission letter will be sent to your email with fee structure.
• You will need to make payment of at least 70% of the tuition and acceptance fee for you to be granted access to the course applied for.
• After making the payment an email will be sent to your email with access link to your registered course.
• You study online and can come to school every semester for exams.

FEE STRUCTURE

Tuition per Session

Tuition Fee = ₦480,000

Application = ₦10,ooo

Acceptance = ₦ 20,000

Course kit =₦30,000

Administrative Charges = ₦60,000

Project supervision = ₦20,000

Convocation = ₦40,000

Total = ₦650,000

CURRICULUM

Requirement Engineering

A Multi Criteria Decision Analysis Technique for Non-Functional Requirements Conflicts

Introduction
Non-Functional Requirements play a critical role in the success of software projects.
They address the essential issue of software quality [1-3] and they are also
considered as the qualifications of operations [4, 5]. Prior study reveals that there
are 252 types of NFRs listed in the literature [6]. Among them, 114 types correspond
to the NFRs perspective in relation to the “quality”. This huge number reflects how
NFRs can be more critical than individual Functional Requirements (FRs) in the
determination of a system’s perceived success or failure. Neglecting NFRs may lead
to software failure, as discussed in a series of systemic failures in the literature [6-9].
Utilizing TOPSIS: A Multi Criteria Decision Analysis Technique 2
NFRs are interacting, which means that they tend to interfere, conflict, and
contradict with one another [1]. Achieving a particular type of NFR can hurt the
achievement of the other type(s) of NFRs. Unlike FRs, this inevitable conflict arises as
a result of inherent contradiction among various types of NFRs [1, 2]. Certain
combinations of NFRs in the software systems may affect the inescapable trade offs
[2, 8, 10]. Dealing with and managing NFRs conflict is essential [11], not only
because conflict among software requirements are inevitable [1, 12, 13], but also
because conflicting requirements are one of the three main problems in the
software development in term of the additional effort or mistakes attributed to
them [13]. A study of two-year multiple-project analysis conducted by Egyed &
Boehm [14, 15] reports that between 40% and 60% of requirements involved are in
conflict, and among them, NFRs involved the greatest conflict, which was nearly half
of the total requirements conflict [16]. Therefore, since conflict among NFRs have
also been widely acknowledged as one of NFRs characteristics, managing this
conflict as well as making this conflict explicit is important [17].
This paper presents the outcome of our longitudinal study of investigating
conflicts among NFRs. Utilizing TOPSIS, an MCDA technique to resolve the NFRs
conflicts is presented as the novel contribution of the paper. Integrating TOPSIS with
our foregoing sureCM Framework can assist software developers performing NFRs
conflict decision analysis quantitatively.
This article is organized in five sections. The first section is the introduction to
NFRs and conflicts among them. The second section describes the research
background and some earlier works. The use of TOPSIS for NFRs conflict decision
analysis is presented in section three, continued by illustrating an example of how
TOPSIS can be applied in NFRs conflict management in section four. Then, section
five concludes this paper by highlighting some open issues that have emerged from
the investigation.

[more…]

 Pair-Oriented Requirements Engineering Approach for Analysing Multi-lingual Requirements

Introduction
Multi-lingual communication is common in countries that have a mother-tongue other than the pervasive
English language. In Malaysia, whose primary language is the Malay language, “code-switching” between
English and Malay has become a common practice of communication [1]. Code-switching has also become a common practice in the Malaysian IT
industry. Considering that the Malay language is the official language of Malaysia, this language is commonly
used in the government IT sector, especially in writing the requirements of a system, and when eliciting or
capturing requirements from clients or stakeholders who are not fluent in English. Meanwhile, the English
language is commonly used in the business IT sector. This situation leads to a plethora of multi-lingual
requirements – those expressed in both Malay and English languages, or a mixture of both [1]. Working with
multi-lingual requirements, software engineers need to be proficient in both languages to be able to capture
quality requirements that meet the needs of the stakeholders.
There are a wide variety of methods for modelling and analysing software requirements. These include
goal-oriented, viewpoint-oriented, agent-oriented and object-oriented approaches [2-4]. Although the
benefits of these methods are widely recognised, software engineers need a high level of understanding and
skill to be able to capture and analyse requirements. As such, besides dealing with multi-lingual issues,
software engineers also face difficulties to handling various tools for analysing requirements used in the IT
industry.
Considering the use of both Malay and English language in the Malaysian IT industry, students of software
engineering in the Malaysian institutions of higher education are exposed to multi-lingual requirements. These
students need to be familiar with IT terms and scenarios in both languages so that when they enter the IT
industry, they will be able to function effectively in this environment. Further, it has been reported that many
students have trouble in capturing requirements using semi-formal or formal models such as UML, tabular
models, algebra or mathematics [5].
Motivated by these issues, we propose a new approach for requirements capture and analysis, Pairoriented
Requirements Engineering (PORE). We expect this approach to be suitable for novice users who in
this case face two main issues in software development. The first issue relates to knowledge and skills of the
various methods to analyse requirements, and the second issue relates to the analysis of multilanguage
requirements. The PORE approach builds on our earlier work to support the development and analysis of
multi-lingual requirements using the EUC modelling approach [1]. In our earlier work, we have developed a
new toolset for developing and evaluating EUCs in the English language 0,0 only. In that body of work, we
adopted the EUCs approach due to its simplicity and understandability by stakeholders, findings that were
supported by our evaluations. As a result, we were keen to investigate whether the advantages we had
observed with EUCs could be extended to multi-lingual requirements, namely requirements in English and
Malay language
In this paper, we introduce our new Pair-Oriented Requirements Engineering (PORE) approach using the
Essential Use Cases (EUCs) modeling approach to capture and analyse multi-lingual requirements. Considering
students as novice practitioners (software engineers), we investigated its application with two cohorts of
students, each cohort taking one of two software engineering related courses, Requirements Engineering and
Software Testing, at the Universiti Teknikal Malaysia Melaka, a public university in Malaysia. Specifically, we
were interested to investigate whether a pair analysis approach using EUCs leads to better results in
comparison to individual analysis undertaken by students. The focus of this study is to investigate the
outcome of working as a pair rather than how the students work together. Therefore, our key research
question is:
“Do students working in pairs perform better than students working individually in analysing multilingual
requirements using an Essential Use Case modelling approach?”
In this paper, we report the outcomes of the two experiments to determine the effectiveness of the PORE
method for capturing and analysing multi-lingual requirements. In each experiment, the time taken and the
accuracy (score) of the students’ EUCs analysis of requirements expressed in both Malay and English languages
are evaluated. Based on the correlation between time taken and the correctness of both languages, the
results of this research indicate a positive result when PORE is used.

[more…]

A Process-Oriented Conceptual Framework on Non-Functional Requirements

Introduction
Software requirements, derived from stakeholders’ needs and environment constraints, guide software
development and determine whether a target software meets the intended purposes [1,2]. Requirements
engineering, also called software analysis, is the process of eliciting, analyzing, specifying, validating, and
managing software requirements. The primary focus of requirements engineering has been functional
requirements, which specify functions that a system or system component must deliver to users [3].
Increasingly, both researchers and practitioners realized that there exist many other requirements that
play important role in shaping the target system, defining the development process, and managing the
development project [4]. Non-Functional Requirements (NFR), as an umbrella term, then was coined to
name these requirements [5].
Noticed the importance of NFR, researchers have paid much efforts on clarifying NFR from functional
requirements and have proposed plenty of NFR definitions over the last three decades [6,7]. For example,
Chung et al. define NFR as any “-ilities”, “ities”, along with many other things that do not necessarily end with
either of them, such as performance, user-friendliness and coherence, as well as concerns on productivity, time,
cost and personal happiness [6]. Unlike Chung’s broad NFR definition, Glinz rules out the process
requirements and project requirements from system requirements, which include functional requirements
and NFR. Glinz defines NFR as an attribute of or a constraint on a system, where an attribute is a performance
requirement or a specific quality requirement and a constraint is requirement that constrains the solution
space beyond what is necessary for meeting the given functional, performance, and specific quality
requirements [7]. Unfortunately, none of these definitions has been adopted as consensus in the community
partly due to the diversity, subjectiveness, and relativeness of NFR [4,6,7,8].
Although it is not clear what NFR exactly is, it has been widely agreed that NFR should be explicitly
handled during software development and maintenance process in order to get software systems with high
quality [6]. However, existing NFR definitions, such as the two afore-mentioned ones, provide very little
operable guidance on identifying and specifying NFR, and on clarifying relationships between NFR and
functional requirements, other NFR, and other artifacts in software development. To this end, requirements
engineering community took a process-oriented approach to elicit and model NFR in software development
process, such as the well-known NFR-Framework [9]. NFR-framework models intermediate artifacts of
analyzing and operationalizing NFR as an AND/OR tree [9,10], which could then be used to justify design
decisions [6].
Software architecture community also noticed the fact that NFR plays an important role in shaping
software architecture while usually remaining implicit or obscure. They also took a process-oriented point
and argued that software architects should analyze and refine NFR before or during software architecting
[11]. However, an aftermath is that the borderline between NFR and design knowledge-related artifacts,
such as design issues, tactics, design rationale, and even design decisions, is likely to be blurred in practice
[8]. Furthermore, the two threads of research efforts that share the fundamental idea of processorientation
differ from each other in terms of understanding, modeling, and managing NFR. This partially
hinders the adoption of these approaches in practice because stakeholders in one community usually do
not understand (hence cannot use) an approach initially invented to solve problems of another community.
We argue that the idea of process-orientation requires a revamped NFR definition that helps stakeholders
unambiguously understand NFR in whole software development process. This paper proposes a processoriented
conceptual framework that concisely characterizes the essence of NFR identified in different
development phases in a unified manner. Specifically, it explicitly distinguishes NFR from applicationindependent
domain knowledge, such as quality attributes, tactics, and other constraints, and then defines
NFR as the composition in specific contexts of domain knowledge and various system abstractions, which
include not only the target system, but requirements model and software architecture that conceptually
define the system at early stages of software development.
The proposed conceptual framework of NFR has two main benefits. First, it uniformly models the
relationships between NFR and functional requirements, other NFR, and other intermediate artifacts
produced in software development, which provides stakeholders an operable and consistent guideline, a
checklist, for NFR identification and management in software development process. Second, it implicitly
regulates the fundamental capabilities that a desired NFR modeling approaches should deliver, which can
guide the improvement to the existing approaches or the invention of more practical approaches for better
adoption. We analyze the methodological implications of our framework and then discuss the fundamental
capabilities of a desired NFR modeling approach.
The rest of this paper is organized as follows. Section 2 analyzes what processorientation means to NFR.
Section 3 proposes the process-oriented conceptual framework on NFR. Section 4 defines the checklist for
NFR identification. Section 5 analyzes the methodological implications of the proposed framework on
understanding, modeling, and managing NFR. Section 6 introduces related work and finally section 7
concludes this paper and foresees our future work.

[more…]

Software Quality Engineering_ Testing, Quality Assurance

Risk Management and Inspection

Introduction
The requirement engineering (RE) process is an essential part to the success of a medium to large project . Software requirement specifications (SRS) are the key artifact in RE , and therefore are related directly to the overall success of a software project. Incomplete, ambiguous, inconsistent or somehow deficient SRS are even considered as the direct cause for project failures . Still companies have difficulties with SRS and are not satisfied with their results.
Consequently, research exists in the field of SRS improving. The IEEE-830 standard (1998) presents a set of criteria that define high quality SRS: Correctness, unambiguity, completeness, consistency, ranking for importance and/or stability, verifiability, modifiability and traceability.
Approaches exist, which directly address ambiguity (Nocuous Ambiguity Identification (NAI), Collective Intelligence for Detecting Pragmatic Ambiguities [17]), incompleteness (Marama based on EUCIP) or some other issue. Alternatively, some approaches attend to solve multiple issues at the same
time (QuARS). One well-known method-type that addresses several issues at once is the review method.
Related to the IEEE-830 standard [15] criteria set for SRS we classify SpeedReviews to focus on the following criteria: correctness, unambiguity, completeness and consistency. The term Speed-Review and its concept are inspired by the idea of speed-dating. Speed-dating is based on quick rounds where the attendees switch tables to meet someone new. Each round is limited by a maximum time limit. We perform the case study at one of the largest automobile trade companies in Europe that provides dealer management systems for the international market.
In Sect.2, we present alternative review methods and explain the SpeedReview procedure detailed in Sect.3. The case study design and research questions are shown in Sect.4. Afterwards, we provide our results in Sect.5 and discuss them in Sect.6. In the last Sect.7, we round up the case study and talk aboutfuture work insights.

[more…]

Towards a Perspective-Based Usage of Mobile Failure Patterns to Focus Quality Assurance

Introduction
The market for mobile devices is rapidly growing [1]. Furthermore, new mobile applications are continuously developed and shipped. Especially in the context of mobile business applications, several advantages are expected, e.g., higher availability, quick distribution of new information, and faster reaction time. However, as it is true for software development in general, a high quality of such applications is a necessity due to the risk of severe consequences, such as lost revenue or reduced efficiency. For example, consider a mobile application for production process control, which offers (i) information about the current status for monitoring the production, and (ii) decision support, like the collection and interpretation of environment parameters. An application failure © Springer International Publishing Switzerland 2015 could lead to wrong decisions or unintended production effects, controlled by the mobile application. In this
example, the usual consequences are very costly due to the high runup time of production processes.
During the last decades, several quality assurance methods, techniques and tools were developed and are usually applied during software development. For instance, different inspection [2] and testing techniques [3] support, e.g., quality assurance engineers, inspectors and testers, to ensure the high quality of a software. However, as the mobile trend is relatively new, such quality assurance techniques are barely adapted to the new needs and
challenges, such as:
• Mobile applications are developed in short, often agile, development cycles, and a fast time to market is
expected.
• The set of requirements as the basis for the implementation and also for testing is changing during the
development.
• Quality assurance is often unfocused due to unknown failure patterns in the mobile domain.
Consequently, compared to traditional quality assurance, mobile quality assurance has to be adapted to these
new challenges by an approach, which aims eventually at being more efficient to be suitable for short development
cycles, and being more effective by coping with a changing test basis and by focusing on typical failure patterns.
Failure patterns represent the relation of fault aspects and their corresponding failures.

[more…]

An Exploratory Study on Risk Estimation in Risk-Based Testing Approaches

Introduction
Risk-based testing (RBT) is a type of software testing that explicitly considers risks of the software product
as the guiding factor to solve decision problems in all phases of the test process, i.e., test planning, design,
implementation, execution and evaluation. It is a pragmatic and well-known approach to address the
problem of ever limited testing resources based on the intuitive idea to focus test activities on those
scenarios that trigger the most critical situations for a software system [1]. Risk estimation is a core activity
in every risk-based testing process because it determines the significance of the risk values assigned to
tests and therefore the quality of the overall risk-based testing process.
A risk is the chance of injury, damage or loss and typically determined by the probability of its
occurrence and its impact. As it is the chance of something happening that will have an impact on objectives
[2], the standard risk formalization [3] is based on the two factors probability (P), determining the
likelihood that a failure assigned to a risk occurs, and impact (I), determining the cost or severity of a failure
if it occurs in operation. Consequently, estimating the risk exposure of a feature or component requires
estimating both factors [4] either implicitly or explicitly.

[more…]

Project Management in New Product Development

CREATE A CULTURE OF IDEAS

The Soul of Innovation and Creativity

The essential ingredients in delivering successful new products and services are
the key people involved and their creative ideas. It is not process, it is people.
Success comes from a vibrant and energetic organization that encourages its
creative members and partners to think innovatively about what they are doing.
They think about where the company is going, and what it can do in the future.
They should feel free to generate and integrate new ideas, products, service
concepts, and processes into the system. In the best companies, new product
development is a mainstream activity driven by vision, organizational energy,
top leadership, and lastly, process.

[more…]

Strategic Alignment and the New Product Portfolio

New Product Portfolio

Especially in middle to large companies (100 employees and up), new products
typically evolve out of a company-wide, strategic process of generating ideas,
conceptualizing them into opportunities, new products and new services, and
conducting an evaluation process that qualifi es them for the company’s new
product portfolio. A new product portfolio is a collection of new product
projects that have been generated, evaluated, and selected on the basis of their
estimated business value, fi nancial performance, alignment with business
strategy, and risk management potential. They may or may not be funded. This
discussion of a new product portfolio will focus on the Eastern case study, and
how the process works from initial business planning through to selection and
funding of new product candidates. This case study will provide a business
application of new product portfolio development.
A new product concept becomes a project when it is selected to the portfolio
and then funded with resources and company support. As the new product or
service concept is being analyzed for selection, it is still a concept, not a project.
Project identifi cation begins when the company gives it resources, establishes a
project team, and authorizes it as part of the company-approved portfolio.

[more…]

PROJECT INTEGRATION AND SETUP

Project Management System

While new product development is often an open-ended process, the
company must have a system in place for making new product decisions. A
company can lose control of new product development projects unless there
is a working and integrated project management system in place. New
products raise critical risks and decision options during development and are
frequently open-ended until development is nearly completed; therefore,
control and analysis must be integrated into the process at every key
juncture.
Project integration management, or integrated program and project
management as it is sometimes called, involves selecting, coordinating, and
synchronizing projects in a company or agency so that all the key factors for
success are optimized. Program managers see both the big picture and the
details of program and project work, all at the same time. The project review
process is set up so that management can make go or no-go decisions at each
key transition point from one phase to another.

[more…]