Sie sind auf Seite 1von 6

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

CSC 3324 - Software Engineering I


Mohamed Ennahdi El Idrissi Amine Bellamkaddem Salah Zouiri

Fall 2012

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

Contents
1. 2. 3. 4. 5. 6. 7. Project General Context ................................................................................. 3 Team Members .............................................................................................. 3 Client Presentation ......................................................................................... 3 Operational Feasibility .................................................................................... 3 Advantages of the New System ..................................................................... 4 Time Schedule ............................................................................................... 5 Conclusion...................................................................................................... 6

Fall 2012

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

1. PROJECT GENERAL CONTEXT The context of this project is to combine academic notions assessment with practical assignments to fulfil a complete grasping of the CSC 3324 Software Engineering I Intended Learning Objectives. Hence, we had the responsibility to seek a topic for our project, encompassed in a professional domain in order to build a reliable professional software for a concrete client. Such a task would inevitably require from us, students involved in this project, to seam the theoretical knowledge with the real life situation when facing a "customer" for which we are commended to yield a respectable product. Mentioning the product brings back and forth an essential part of software engineering: process. Arguably, we need to take into consideration process attributes to generate a product with suitable attributes, which means that the product is an internal, and forcibly, an academic business, in contrast with the product, which is the professional side of this activity. Our project is about an association which operates in the agricultural field in Morocco, and it is located in Agdal, Rabat. During our first meeting, Mr Seddik Zniber acknowledged that he is in need for a software to automate his daily endeavours. 2. TEAM MEMBERS Mohamed Ennahdi El Idrissi Amine Bellamkaddem Salah Zouiri MSSE MSCS BSCS m.ennahdielidrissi@aui.ma a.bellamkaddem @aui.ma s.zouiri@aui.ma

3. CLIENT PRESENTATION Founder Association Name Field: Address Phone Operating since Seddik Zniber Association Nationale des Eleveurs de Bovins Agriculture 5 Rue Mohamed Triki, Rsidence Tissir, Imm. B Appt. N2 Agdal 10090, Rabat +212 61 00 00 00 1990

4. OPERATIONAL FEASIBILITY The project we are intending to realize has as outcomes the relief of semi-manual information management (non automated excel sheets), omnipresent data inconsistency risks and absence of backup, inefficient/rigid search of elements (organismes, rubriques, etc.), and reconstructing the displaying/labelling structure whenever it is subject to add a new "organisme".

Fall 2012

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

Going toward the automation of the abovementioned aspects would enhance the ANEB association performance, conciseness, and precision. Moreover, it would reduce misunderstanding and confusedness with the different clients (organismes) it is dealing with. Investing in such a project wouldn't only help the association to yield better management results but also allow it to archive data, to generate reports deduced from the latter, etc. ANEB association deals with a number of client organisms, and those gather a number of adherents who own their own cattle. Adherents can be individuals or cooperatives. Each organism owns a number of rubrics, but an organism A's rubrics may (not necessarily) differ from the rubrics of an organism B and so forth. The same concept can be applied on subrubrics (Sous-Rubriques), except that starting from this level, values can be represented. Subrubrics may also gather infra-rubrics, which behave as sub-rubrics (value presentation). A sample structure is as follows:

Organism

CEBG
Programme d'insmination artificielle
Nombre de vhicules IA : 10 Nombre de circuits IA : 9

Rubrics

Donnes Gnrales
Nombre d'leveurs individuels: 40

Sub-Rubrics

Nombre de coopratives: 50

Infra-Rubric

Nombre d'leveurs: 150

5. ADVANTAGES OF THE NEW SYSTEM The future system will provide graphical user interfaces that will allow enhanced data management (display/update), in addition to the smooth navigation between different elements of the each organism. Deducing the amount of certain sub-rubrics (or eventually infra-rubrics) would be performed automatically. Users can sort the shown data as well as applying tight searches on specific items. Reliability + Usability. Once the data is centrally stored, the risk of data inconsistency is reduced, and the intrusion deficiencies are minimized. Users of this future software can rely on it since it is customized specifically for the ANEB itself. Dependability.
4 Fall 2012

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

Our client requested that the software should be able to evolve to meet future requirements. Maintainability. The client also insisted on the fact that the application should be available online, which means that it should be continuously available from anywhere (The client is subject to operate in rural areas, hence the wished capacity of immediate access to the software). Availability. We would like to emphasize on the fact that the client wishes to be able to have an "infinite" depth hierarchy, meaning that for the time being, the hierarchy is constituted of four elements, but each element should possibly have children as it has a parent (e.g. an infrarubrics can as well be the parent of other elements - Recursive relationships). Meanwhile, the client stated that he wants to be the single user of the software (no need for a system which accepts multi-users for now). 6. TIME SCHEDULE Weeks Number Week 1, 2 Parts looking for a client 1st meeting with our client Proposal 2nd meeting with our client Feasibility study Requirements Engineering: Collecting Analyzing Documenting 3rd meeting with our client System and Software Design 4th meeting with our client Implementation and unit Testing 5th meeting with our client Integration and System Testing 6th meeting with our client Project Demo and Presentation

Week 3 Week 4, 5

Week 6 Week 7, 8 Week 9 Week 10, 11, 12 Week 13 Week 14 Week 15 Week 16

Fall 2012

SOFTWARE ENGINEERING I

FEASIBILITY STUDY

7. CONCLUSION ANEB project will be, no doubt, a good opportunity for the team members to work on a real-life project and learn how to deal directly with the end client. Thanks to this experience we will get a concrete idea about the whole life cycle of a real project.

Fall 2012

Das könnte Ihnen auch gefallen