IT Project Kwa Vitendo

redSilverDog said:
Mtazamaji listi yako vipi? Huu si ndo ule wakati wa kutoa inactive team members. Maanake nnavyoona kuna watu nje wanawashwa (Not rude tone!!) wa-take part na kuna wengine wapo ndani hawapoactive!:A S thumbs_down:
Click to expand...
Mkuu documents tusazisoma, kilichobaki ni kuanza kukusanya data ili kazi ianze.
 
redSilverDog said:
Mtazamaji listi yako vipi? Huu si ndo ule wakati wa kutoa inactive team members. Maanake nnavyoona kuna watu nje wanawashwa (Not rude tone!!) wa-take part na kuna wengine wapo ndani hawapoactive!:A S thumbs_down:
Click to expand...

Nilikuwa nasubiri uniambie. sasa kama kuna mtu nitakuwa nimemtoa kimakosa utanijulisha. nimrudishe au kama kuna newmember amerequst nipe ruhusa nimuweke.

Kwa kuwa tuko kwenye ealry stages nadhani ni sawa kuingizaa 3 or 4 new people but at some stages kutakuwa hakuna new mebers .

Mkuu documents tusazisoma, kilichobaki ni kuanza kukusanya data ili kazi ianze.
Click to expand...
Nadhani kama kama umemuelewa team leader team member hatutakiwi kuishia kusoma tu .tunatakiwa kuchangia some ideas La sivyo kutakuwa hakuna faida ya kuwa project member
X-paster said:
Ndio maana yake, tugawane majukumu au tuanze kukusanya data muhimu.
Click to expand...

Mkuu tutagawana majukumu gani bila mipango(Plan) bila kukubaliana requirements na design and modal Bila hizi hatua hatuwezi kuelewana hata huko mbele itakuwa ni vurugu tu. Hapa lengo si tu kutengene za online directory lengo pia nikujua na kupitia japo process za system au project development .So kama member tuendelee kushirikiana kutoa ideas na comment katika hizi hatua za mwanzo amabzo ni muhimu. Na kwa hatua hizi hata huko mbele wote tutaongea lugha moja.

Nadhani wengi walikuwa interested na implimentation side of project. Kwa kuwa tuko mbali hatuwezi kufanikiwa hata 20% bila kuelewa na kushirikiana kwenye hizi hatua za mwanzo mwanzo. Hata member tungekuwa ofisi moja bado stage kama Requiment analysis and preliminary or detail system design ni muhimu.
 
redSilverDog said:
I am sure it misses a lot. please tell..
View attachment 21907
Click to expand...


Boss nimesoma Use case yako i can isee iko ina details sana . wasiwasi wangu au ushauri wangu ni twende na scope ndogo kwanza.


Observation and Views

  • Users wako wa aina mbili
  • Web user ambaye sio lazima awe resgitered ambaye anatakiwa awe na uwezo kwa ku view all available information na kuweka comment au review hata kama anonymus
  • Registered user ambaye awe na uwezo wa ku edit profile yake.
Nadhani hapa tuna challenge sababu kuna watu watakaohitaji kusajiliwa wanaweza wasiwe watumiaji wazuri wa internet. Vipi Muuzza butcher akipiga simu kuomba biashara yake isajiliwe. ? Au dereva wa Taxi au lorry anapigasimu uomba asajiliwe taarifa za kazi/ biashara yake.

Nadhani Unlesss sio Private/ personal information basi mlolongo wa confirmtion usiwe lazima sana .


Price Comparison
I suggest this capability be considered in later future system maintenance projects . For the current project objective iwe ni kusajili contact information za watu, taaluma, huduma , serikali, viongozi wa umma, biashara


So nadhani capability ya comparison isiwe kwenye scope kwa sasa labda baadae.
 
Reasonably, tutascrap price comparison.

Confirmation, hatutofanya sisi, itakuwa automated ni yeye na system. Akijaza form, akisubmit atapelekwa kunconfirm kama alichojaza ni sawia, then basi!
 
X-PASTER said:
Mkuu mimi nitasaidia kidogo kwenye html, javaScript, CSS na Photoshop na kama kutatakiwa Kusajili domain name basi tufahamishane.
Click to expand...


I am CCNA graduate... though sija seat for the final.. i have an experience of 6 yrs in industrils na pia nina basic nokweledhe kwneye mysql and PHP. na kidogo visual basic... na ni mtumiaji mzuri wa open source. UBUNTU OS na package zake... ingawa kazi ninayofanya ss hv imeniweka out of field kwa takribani 4 months now. nawakilisha
 
redSilverDog said:
Reasonably, tutascrap price comparison.

Confirmation, hatutofanya sisi, itakuwa automated ni yeye na system. Akijaza form, akisubmit atapelekwa kunconfirm kama alichojaza ni sawia, then basi!
Click to expand...

hapo kwenye confimation naona techniçally ni nzuri kama unavyo sema lakini informationally site inaweza kuwa haina maana kama either data zitakuwa feki, hazitoshelezi mahitaji ya walengwa, too much redandancy, wapo wale wakao shindwa, etc.
 
oK hiii stage a requiment itabidi twende nayo kwa muda na tuwekane sawa. na kukubaliana

  1. Tunaposema user ana view information inabidi tufafanue ni information gani ni zipi ni za muhimu ni zipi ziwe za lazima?Mnaonaje tukiendelea kubrain storm in detail
Ingawa hatujafika kwenye datababase design input za hizi use case tukizichimba ndani kabisa na kutumia muda hata huko kwenye DB hatutapata kazi.
 

Tuseme mtu hajajisajili kwenye wavuti yetu, na anataka haraka haraka kujua garaji ya karibu iliopo nae. Atatabahath kwenye wovuti yetu na atapata nambari za simu, mtaa, (na kwa baadae hata ramani).

Sijui umeelewa maanake hapo juu nimetumia kiswahili kitupu!
 

Ok PL ndio nilikuwa nataka tuchambue hivyo inagawa ni nadhani wote tunafahamu ndio lengo hasa putting our use case in more detail tundoe ambiguities . Bcs i can kuna vi complication hapa .tuseme sasa huyo mtu atapesa macho kuona hiyo gerage au inadidi tuwe na category fulani ya vitu muhimu amabvyo.

mfano mimi ni user nataka kujua gereji au fundi wa gari au IT aliye karibu na bunju..
Nainngia kwenye website yetu hii wht will i do to get a list of garege names names


  • Will i oruse need to browse the whole database
  • Will there be categories of some field for user to chose from to minimise his search option
  • If there will be some categories wich sould be major categery kumuwezesha user kupata infor anayotaka?
moja ya kazi ya use case pia ni kubrain storm user inteface ndio maaana nakuja namaswali haya ya kizushi. smetime wee need to assume client or end user role.

.So far

  1. Tumendika Siple plan amabayo ndio kama inatuguide na Inafanywa changes acccorindly project inavyokwenda
  2. Kwenye requiment tume fanya USe case wich i think is sufficient.
Je sould we be concened with specifying minimal non functional requiment. Kama
  • security. This should not be an issues bcs system yetu haina haina critical data . Just simple security protocol and implimentation ziatumika where neccessary

  • Acccesibility Mobility/Scalability. Though hii prje itakuwa bomba zaidi kama hii system itaweza kupatikana hta kwenye mobilen sijui mnasemaje tukiliweka hili kwenye Phsase 2. Imean baada ya proje kwisha tutacheki ni mabadiliko na nyongeza gani tunahitaji

  • Availability- harware resouces zitakazo host system yetu ziko outside scope yetu na control yetu . So even some of functional requiment zinaweza kuwa affected. sometime
 

Sawa sawa, ofcourse lazima tuweke categorised serach ili iwe rahisi. Okey next nadhani ni REQUIREMENT DOCUMENT au?
 

Information atakazo ziona user wa kawaida, ni zile ambazo tutakuwa tumeruhusu zionekane.
Mf: Jina la uduma anayoitafuta, mahala zinapo patikana na anuani zake na nambari za simu.

User anapoperuzi kwenye wavuti yetu anatakiwa kuona mambo haya yafuatayo: Search by Category: (with drop menu)
Hapa zinapatika zile uduma unazo tafuta Mf:

Advocates, Lawyers Commissioners for Oaths, Agricultural Commodities , Agricultural consultants, Air Charters, Computer Consultants, Computer Hardware, Software Maintenance Services, Computer Stationery Suppliers, Computer Training, Hospital Medical Services, Hotel, Motels, Restaurants etc

Search by Name:
Hapa utaandika jina la uduma unayo tafuta.

Search by Location:
Hapa yanapatikana majina ya mikoa au ile sehemu ambayo mtumiaji anatafuta huduma husika

Mf:Arusha, Bagamoyo, Bukoba, Dar es Salaam, Dodoma, Himo, Iringa, Kagera, Mwaanza etc
 
Recommendations:
Since directory services as a web application already has been implemented all over the web, I suggest that a visit to such sites should be undertaken to collect likely features that you need to build into your solution.
The best directory service is only brought about by a well crafted data input. Once all relevant data is available, then it even becomes easier to allow a user to determine how they run the search. I might be looking up certain businesses in TZ as a whole, for a specific business sector hence my search might originate from doing a generalised search based on the sector itself.
However, if I am looking for a doctor, I would want to include the region (Dar es salaam) and preferably Sinza as a sub category but all this depends and relies on the underlying data being made available at business registration to the site.

In Tanzania do towns have individual tel code?

Please visit yellowpages as a start, since this is a global business, different countries may implement it differently hence you could see how best to build that part of the application.
Yellow Pages® | Your Local Australian Business Directory
http://www.yellowpages.ca/
Yell.com the UK's local business search engine - search for London businesses
...


Feature Set
Best approach here is to build in as early as possible all the features that the application may require. Retrofit of features may prove to be damn expensive on time and expertise. If the underlying infrastructure is not following a module form of application build where plugging in new features is a well documented activity, It would almost mean that a new application is being built every time a new feature needs to be added. The trends are that more mobile users are accessing the internet and given that there are issues with the internet access (traditional PC based), it means that within the region, a big number uses/accesses the internet on mobile form. Hence can't rule them out in the build.

Security
Building an application from ground up is not advisable even though it is assumed that the data is not critical. Again, does depend on how you view telephone and address details, for me I think they are critical. If bots and online software that are written to harvest data from unprotected sites hits this site, you can't tell where that data will end up and if any issues will arise from that. A directory service is assumed to be a user centric application, and that each result is a result of a user activity (click to search) and hence implications may be different in that instance. Other security issues ie, Trojan code being embedded into your app/web that cause havoc on user sites will undermine this effort. As an example, I used to visit one prominent News site in Kenya, will not name it so that you don't encounter similar problem but their web did throw up a few security alerts when I accessed it hence already I shy away from the site and maybe will never visit it again, even if someone tells me the error is fixed.

I think you might also need to implement an opt-in/out clause since most of the data could at some point become commercially usable. Example, a company needing to do a market research through the addresses (especially e-mail) available from the site.
If a user is happy, then, can legally provide that to the company for their mailshot to be disbursed.

Availability
I am not familiar with the .tz registration requirement, but if it ties you down to hosting in TZ, then I would not recommend it. Rather you use a .info or a .net hosted in the cloud that will for one ensure a reliable fast service for your clients.

Access to data
This should be viewed as a public service site. Access should be automatic as far as searching the site is concerned. Access rights however should/could be implemented where a user becomes an originator of data. You will need a way to communicate with them if required hence e-mail storage may be requested as part of the input.

Data currency
You will also need to keep the data current and that can only be done by periodically prompting the originating user via e-mail to ask for confirmation of this else over time, a site will/could hold junk data. A mechanism to delete data not confirmed or updated over a certain time will need to be agreed upon.

 
You must log in or register to reply here.

Similar Discussions

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…