WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

The implementation of web based system for the improvment of good governance in the development of rwandan districts.

( Télécharger le fichier original )
par Herménégilde HUNDWITIRO
National University of Rwanda - Bachelor Degree 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

CHAPTER 3. METHODOLOGIES USED

3.1 Introduction

This chapter puts in relief the different approaches that were used to optimally get the best solution to the users' needs .This part describes in details the Software Engineering methodology used and finally the tools used to implement the chosen approaches.

3.2. Software engineering approach

3.2.1. Software life cycle

A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired.

(Retrieved April 18.2009.from;http// softpanorama.org/SE/tware_life_cycle_models.shtml,).

It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables.

Typically, a life cycle model addresses the phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker" or corporate IT bureaucrat (which is probably ten times dangerous then undisciplined hacker). As always, it is a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.

Software life cycle models describe the interrelationships between software development phases.

Figure 3.1: The classical sequential software life-cycle model

 

Problem

 
 

System Specification

System and Component Design

Operation and Maintenance

System Test

Implementation and Component Test

 

Requirement Analysis

Source: Own drawing

3.2.2. The waterfall model 3.2.3.1 General Description

The waterfall model was developed in the 1970 by Royce. The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.

(Retrieved April18.2009.from; http://en.wikipedia.org/wiki/Waterfall_model,).

It should be readily apparent that the waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. Ironically, the use of the waterfall model for software development essentially ignores the 'soft' in 'software'.

It provides for varidation of the phase outputs in the software life cycle. This approach modifies the strictly sequential approach prescribed by classical life-cycle model and advances an incremental development strategy. Incorporating a stepwise development strategy for the system specifications and the system architecture as well as phase - wise validation helps to better manage the effects of poor decisions and to make the software development process more controllable.

Requirement

Design

Implementation

Verfication

Maintenance

Figure 3.2. The waterfall model Source: (Retrieved April.18 .2009

from http://en.wikipedia.org/wiki/File:Waterfall_model.svg )

3.2.3.2. Limitation of Waterfall model (RetrievedJune11.2009.from; www.site.uottawa.ca/school/research/lloseng/supportMaterial/slide s-edition1/htmlSlides/Chapter11/tsld009.htm).

The model implies that you should attempt to complete a given stage before moving on to the next stage

? Does not account for the fact that requirements constantly change.

· It also means that customers can not use anything until the entire system is complete.

· The model makes no allowances for prototyping.

· It implies that you can get the requirements right by simply writing them down and reviewing them.

· The model implies that once the product is finished, everything else is maintenance.

3.2.3.3. The strength of Waterfall model

The waterfall model provides the following strengths:

+ Enabling tracking of project progress more accurately and uncovering possible slippages early.

+ Focusing the organization that develops the software system to be more structured and manageable.

+ Well defined user

+ Development and design standards

+ Tolerates changes in MIS

3.2.3.4. The model consist of six distinct stages, namely

1) In the requirements analysis phase

a) The problem is specified along with the desired service objectives (goals)

b) The constraints are identified

2) In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

Note that in some text, the requirements analysis and specifications phases are combined and represented as a single phase.

3) In the system and software design phase, the system specifications are translated into a software representation.

The software engineer at this stage is concerned with:

· Data structure

· Software architecture


· Algorithmic detail and

· Interface representations

(Retrieved June 18.2009 http://www.softpanorama.org/SE/software_life_cycle_models.shtml )

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed `down stream'

4) In the implementation and testing phase stage the designs are translated into the software domain

· Detailed documentation from the design phase can significantly reduce the coding effort.

· Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5) In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer. Deliverable - The software product is delivered to the client for acceptance testing.

6) The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:

· ?Meet the changing customer needs

· ?Adapted to accommodate changes in the external environment

· ?Correct errors and oversights previously undetected in the testing phases

· ?Enhancing the efficiency of the software

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a `revisit' to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"I don't believe we shall ever have a good money again before we take the thing out of the hand of governments. We can't take it violently, out of the hands of governments, all we can do is by some sly roundabout way introduce something that they can't stop ..."   Friedrich Hayek (1899-1992) en 1984