This web based booking and counseling project was initially conceived for Dilemma Counseling Services as a web system, offering counseling to masses (refer to project proposal). The idea then was to have an online portal where clients can post problems and counselors respond to them. However the core issue was, whether it would be done for free at the expense ofDilemma Counseling time and finances. But as the idea of the web based counseling system was brainstormed by top management, new requirements arose. To maximize potential of the web based system proposed, the management realized their booking system was a mess and resulted in data duplication and clashing bookings. The ineffectual booking system then in place brought constant complaints from clients whose counseling sessions clashed. The Dilemma Staff contracted me to offer expertise on if counseling and booking can be incorporated into a web based system that is financially viable this was possible. So I adopted a Unified Software Development Process (USDP) because after interviewing the various staff I was not satisfied with the feedback. Thus I choose USDP as the software development method since it allows new requirements to be factored at any project stage. Sure enough as the software development process progressed new requirements arose like online counseling system, processing payments made and assigning username and passwords for clients who pay but prefer online counseling as opposed to face to face counseling. The system allows staff to book clients remotely online via secure log in. The clients counseled can have their progress tracked easily via the secure counseling chat system. I stuck to the USDP process and working on each workflow and resultant artifacts like Unified Modeling Language diagrams to ensure the project was well modeled to be realized in construction and transition phases
This project could not have been even a near success, were it not for the positive criticism by my Lecturer Mr. Alfred Emurgat. He was kind and ready to answer all queries I had, and really challenged me to come up with quality high standard work. In addition I would like to thank all my family members who supported with encouragement in moments of workload and pressure.
Chapter 1: Overview
This chapter introduces Dilemma Counseling and what it does, the progress its making and problems encountered and proposed solution(s) to improve on its current operations.
Dilemma Counseling Services is based in Nairobi and has offered counseling services from its inception in July of 1990. It was founded by Eric Owiyo to counsel rape and conflict victims. Initially, it operated on an on offbasis where, victims especially from the slum areas sought help from the founder on confronting various crisis they had. The founder gave general advice but referred some victims to experts he knew could tackle specific problems. As people kept streaming for impromptu counseling, the need for experts was arrived at. Over the next six years, the organization branched into other aspects of counseling. By mid nineties when there were tribal clashes, the staff mobilized resources to aid the victims. Even after the tangible needs were met emotional hurt still remained. That was when Trauma department of counseling was established. As the community needs increased counseling departments were created for specific problems. Currently, they counsel around 20 to 30 victims done by 20 counselors working on rotational basis. Dilemma Counseling services were pivotal this year (2008) especially after post election violence that rocked the country. They counseled the internally displaced people (IDP) and sourced aid for victims in the camps. Dilemma Counseling is contracted at times by the Kenyan government and insurance companies, hospitals religious and human rights group to offer counseling to victims. An example is in the aftermath of elections violence in Kenya, through its Trauma Branch of counseling. Dilemma Counseling is located in Norwich Union Towers Kimathi Street the whole of 4th floor. The person responsible to give strategic direction is the founder. The supervisor checks daily operations ensuring they run smoothly and reports to the founder.
1.2 Dilemma core department is counseling but there are others which I will elaborate. Counseling Department: is the operational spine ofDilemma. It’s headed by a lead counselor who other counselors report to. If one department is overstretched with clients, he takes up some clients himself. He encourages past victims to volunteer. Volunteer counselors are past victims who got counseled and recovered. They relate well with so victims since they have common ground. Counseling Department is divided into sub sections offering advice for specific areas as follows:
a. Marital Counseling counsels couples considering marriage, or couples that are sorry to be married. This department handles couples in need marriage advice. This department organizes seminars in the city for educating couples on issues pertinent to marriage. It’s headed by certified marriage therapist. The problems in this department are inadequate marriage literature to give to couples and few qualified marriage counselors resulting in overworking the resident marriage therapist.
b. Teenage Counseling offers counseling to teenagers on adolescent stage to make right career and life decisions. It targets teens in school and out of schools, to ensure they engage life wisely. It’s ensures teens don’t drift to immoral practices. This department raises funds for projects to engage slum teens to avoid moral decadence. It’s headed by a teen counselor. But this department has struggled to hold consistent clients. An issue has arisen of it being reconstituted to be sexual health department.
c. Children Counseling handles desolate children who were and are emotionally scarred. It restores normalcy and lost innocence to children. This department counseled children after the post election violence. It is headed by a qualified child psychologist. Due to evident need, counseling maybe done free of charge. Some children are at children’s homes struggling with finances for upkeep.
d. Law Advice department is headed by a resident lawyer who gives law advice. Law issues include widows who need court representation on property left behind by husbands. They represent orphaned children to help manage on interim period property left behind by deceased parents. To prevent property miss-appropriations byjealous relatives. It’s the most competitive department at Dilemma but it faces bottlenecks in courts due to backlog of cases it files for its clients.
e. Family Health Counseling It majors on family health. It targets parents who have toddlers or expecting. They also target slum mothers who can’t afford counseling services as community outreach. The department is headed by a nutritionist health officer. However given the health officer works on part time, clients wait for long before getting a session with him.
f. Trauma Counseling handles trauma related cases like rape victims. It also offers stress related counseling. Given the depth of cases, it takes toll on counselors who take days off resulting in client delay. Also follow up is difficult to make for the clients not within
Nairobi city. This department is headed by a trauma counselor and the founder also handles some cases.
Booking Department captures clients’ details and schedules session with the counselors.
Client’s details are taken by the booking secretary. After the client pays, he is given a receipt showing counseling time. Clients may call and the secretary books a session, as clients pay to the bank and present bank slips as payment evidence. There are factors, overwhelming this department, when booking records are lost and clients are double booked at the same time. Human Resource Department: handles staff hiring for Dilemma. It works closely with the founder to ensure competitive staff is hired. It is run by a human resource manager who vets applications that come to him and passes them to the founder for approval. The problem here is the hiring committed staff and sourcing for volunteer counselors.
Accounts Department: handles the finances of Dilemma. It drafts salaries for the staff. And check when clients are due to pay. The accounting department faces challenges of accounting for monies missing due to poor record keeping in the booking department. The accounts department delays client clearance for counseling due to lost records.
Marketing Department: handles the public relations for Dilemma Counseling by highlighting the successes of Dilemma. It even invites past victims to public forums on how counseling at Dilemma helped in the healing process. This department sources for clients around Kenya. However client sourcing lately has been problematic due to the reputation of Dilemma of flawed record keeping. It’s headed by a Marketing Manager.
Tracking Department: here victims who have been counseled are followed up to find out their recovery progress. It involves calling or writing to clients and awaiting their response. The challenge here is follow up of counseled clients not within Nairobi.
1.3 For this project the departments likely to be affected by the system are:
Counseling Departments Booking Departments Tracking Departments Accounts Department (partially)
The aim of the web based project is to improve on the current problematic booking system which results in clashed bookings. Also tracking of counseled victims online will be explored. Also the system will allow for remote logging for the staff to perform some tasks online like online client booking.
The Diagram below shows hierarchy with the various departments and sub-departments.
illustration not visible in this excerpt
1.4 Dilemma Counseling Services despite competition and some loss of clients’ still attracts considerable number of major clients per year. This growth has been occasioned by the fact that, even after a victim is counseled and released, there is an effort by staff to follow up on his/her progress. Unlike many counseling services where a victim’s progress is not followed up. That still attracts many prospective clients to be counseled by Dilemma. But tracking clients who are out ofNairobi has proved challenging given the calling costs and inadequacies of conventional letter communication. Clients’ confidence has been eroded by disorganized booking and recording system in place. This affects mostly those who book sessions on phone. The secretaries scribble bookings on papers, and forget to record them. Then another member of the booking department may book a client and two or more clients are likely to be double booked same time. These issues made the management realize, for Dilemma to be competitive in market, an efficient method ofbooking and tracking clients is needed. Dilemma sourced me to perform an analysis of the current system and propose the best likely solution.
Dilemma Management is considering if there is remote possibility of counseling being carried online. After the information it lead me to propose a web based booking and tracking system that prospective clients can log in to and book online. Tracking aspect covers those counseled victims living in far localities to log in and have a real time chat on their progress to counselors.
1.5 Project Plan has likely time the project will take. From it’s financing commencement and implementation. Tasks are procedural with likely time they may take.
Project Financing: concentrates on gathering funds to be spent on the whole project. It runs from January 11to January 14 2008. The deliverable is the finance report.
Research: finding out how current system works and if an online counseling system has been in operation before in similar context. The artifact will be research report with viability. It runs from January 15 to January 20.
Proposal Writing: here I prepare the proposal for Dilemma Management outlining how I will carry out the project. This occurs from January 21 to February 14.
Feasibility Study: will focus on viability of the proposed web based system and its applicability in the problem domain. The feasibility study report is the outcome. Feasibility Study occurs from February 15 to March 20.
Current System Investigation: finds out why the current system in place is a failure. The outcome would be requirement analysis. It occurs from March 21 to April 10.
System Design: coming up with user interfaces for the system for the end users. The deliverables would system interfaces. It occurs from April 14 to May 30.
Progress Report: is continual in nature and can be produced at any project phase to illustrate the project progress. The deliverable is project progress report.
System Development: is constructing the web system as per design specification. The artifact is system documentation Carried out from June 5th to September 3.
Pre-User Introduction: is the interim user introduction where users interact with system before implementation. User report is the artifact. It’s carried out from September 4 to September 19.
System Testing: the system is tested to ensure it meets user requirements. Test report is the outcome. It’s carried out from September 22 to September 30th 2008.
System Implementation: is rolling out the system on problem area to ensure it adapts and meets the expected requirements. Implementation assessment report is the outcome. It happens from October 1 to October 8.
User Documentation: The deliverable is the user manual. It happens from October 10 to October 15.
1.6 The Project Road Map documents all chapters and what’s to be done. From Chapter 4 the project will follow the USDP development process.
Chapter 1: introduces the Dilemma Counseling, what it does, the various departments it has and problems it faces.
Chapter 2: compares the USDP methodology I will use with other methodologies and state reasons for using the USDP as opposed to OMT or SSADM.
Chapter 3: it’s the literature review compares views of various scholars on methodologies as I also give my own view and criticize some scholars.
Chapter 4: it’s the inception chapter where I model the current system and its bottlenecks while explaining the business viability of web system proposed.
Chapter 5: its elaboration phase where software architecture is established to provide foundation for design and implementation during system construction.
Chapter 6: it’s the construction chapter, the system is developed and remaining system requirements realized it ensures the system is ready for user environment.
Chapter 7: it’s the transition phase. Testing is done as the system is configured for installation. The software is then deployed to target organization.
Chapter 8: here I do critical appraisal where I critique my project and offer recommendations to make it better while detailing what wasn’t achieved.
Appendix: contains what could not fit in the mandatory 75 pages like code libraries and excess modeling diagrams.
1.7 The problem for Dilemma Counseling is the flawed booking and tracking system. It’s hoped a new web based system would boost client confidence by discarding the bottle necks of the current system. It would ease the booking and make tracking manageable. That is where the problem domain for this project will be concentrated, but new requirements that come up will be factored too.
Chapter 2: Methodology
This chapter details the methodology I will use to develop the proposed web booking and tracking system and modeling language for software development. Also I will compare the two Object Oriented methods Object Modeling Technique and USDP and argue why I settled on using USDP for this project over OMT.
2.1 A Methodology outlines the procedures, techniques, tools and phases that aid the system developer to know which method and modeling language to use in system development. Examples of methodologies out there are:
Object Modeling Technique (OMT)
Object Oriented Analysis Methodology (OOAM/Booch Methodology)
A Method has steps to be followed in the various tasks carried out during the software development lifecycle from inception to implementation. Examples of methods are Unified Software Development Process (USDP) and Dynamic Systems Development Method. (DSDM).The Modeling Language comes up with software blueprints and represents a real object. Example ofModeling Language is Unified Modeling Language mostly used in modeling in many methodologies like OMT and OOAM since it’s mainly process independent. Object Oriented Analysis Methodology allows modeling in Unified Modeling Language for writing software blueprints and Unified Software Development Process to show the procedures to follow during software development.
2.2 Object Modeling Technique: is software engineering methodology that concentrates with Object Oriented development in analysis and design phases. It was developed by James Rumbaugh. OMT provides 3 views of the system which correspond to 3 system models. The models are defined first and refined in the various phases of OMT progress. The models are Object, Dynamic and Functional models.
Object Model defines the static structure of the objects in a system and their relationships. The main concepts here are class, attribute, operation, inheritance, association (i.e. relationship), and aggregation.
Dynamic Model: describes the parts of a system that change overtime. The model specifies and implements the control parts of the system. The concepts in dynamic model are state, event, action, activity and sub/super state.
Functional Model: describes data value transformations within a system. The concepts are process, data store, data flow, control flow, and actor (source/sink).
Object Modeling Techniques Phases
illustration not visible in this excerpt
Analysis Phase: involves building of a model of the real life situation. It is based on problem statement and user requirements. The problem statement is expanded to 3 views/models which are Object Model, Dynamic Model and Functional Model which form the artifacts of analysis phase. Object Model has object model diagram and data dictionary. Dynamic Model comprises of State Diagrams and Global event flow diagram. Functional Model has data flow diagrams and constraints. Analysis is where most modeling is concentrated.
System Design: The system overall architecture is established. The system is planned into subsystems which are allocated to processes and tasks which consider concurrency and collaboration. The system scope is also established. The deliverable is System Design Document: basic system architecture and high-level strategic decisions. The problem domain is understood and proposed architecture of target system (solution domain) in design phase.
Object Design: the implementation plan is known. Object classes are established with their algorithms with attention being on optimization of the path to persistent data. Inheritance, association aggregation and default values are examined. Deliverables are detailed object model detailed dynamic model detailed functional model. Implementation: the design is translated to particular language or hardware instantiation, with emphasis on traceability and retaining flexibility and extensibility. The deliverable is fully developed software. OMT emphasizes on analysis and design phase for initial product delivery and no emphasis on implementation, testing or other life cycle stages.
2.3 Unified Software Development Process (USDP)
For this project, I will model using Unified Modeling Language and the software development process will be Unified Software Development Process. Phases are procedural in nature. USDP is robust enough, to allow me to revise the system incase pre-defined requirements change. The models ofUSDP next show how I will model the proposed project from inception to transition and associated workflows. Each workflow as per the models below increases decreases or ceases, depending on the phase it’s in.
illustration not visible in this excerpt
Analysis and Design none
USDP has 4 procedural phases they are:
Inception: here the business viability of the project is assessed by the stakeholders through conducting a feasibility study. The scope, cost and supporting environment are discussed. Feasibility study is done in context of: technical, operational and business feasibility.
Technical Feasibility: outlines the hardware and software required for support. Operational Feasibility: assesses how the system will interact with the user environment it’s targeted for.
Economic Feasibility: assesses how when the software is implemented will help reduce the current operational costs.
Here the stakeholders agree with scope definition, costs risks and software development process as the interim milestones.
The deliverables are:
Project Idea Development
Comparison of system in place to proposed system can be (current manual system versus proposed system).
Iteration determination and their requirements
Developing of the project milestones
Business Case for the project identified with estimates.
Major use cases are identified and described.
Identify the staff with likely points of system interaction.
Initial use case model 10% to 20% complete.
Elaboration: the software architecture is outlined to ensure firm foundation for implementation and design at construction phase. Risks are assessed and the software architecture and acceptable costs are ensured to be within the right time frame as milestones in this stage. The deliverables are:
Draft of the proposed project design model
Use case model 80% complete given most use cases have been identified and most descriptions developed.
An executable architectural prototype.
A revised risk list and revised business case.
A development plan for overall with the coarse gained project plan showing iterations and evaluation criteria for each iteration.
Develop a detailed plan for construction and transition phase.
Construction: here the system development is completed based on the model design outlined at the elaboration phase. Here it’s ensured that the system is ready for end user environment. The system is evaluated if it’s developed as per expectations specified in the phase and iteration plans. The functionalities are checked to have been incorporated into the system and passed the formal acceptance criteria in end user environment. The deliverables are:
User manuals are drafted here.
Planning for the transition phase is done.
An executable alpha tested program.
Completion of use case diagrams, collaboration diagrams, class diagrams and sequence diagrams.
Transition: here it’s ensured the system is ready to be accepted by the end user environment. Deployment to the end user environment occurs for aims of testing and quality evaluation. The software is fine tuned and installed being the final release of the executable software. Here previous milestones outlined in earlier phases are realized. The artifacts realized are:
Release of the executable program
Installation of the final product that has been developed.
User support documentation and updated models and documentation are made available for end user reference.
Full documentation for reference and use by end users.
Iterations and workflows in USDP
Iterations basically are mini projects whose overall scopes over each of the four stages are to ensure the system at best meets the pre-defined user requirements. Iteration defines requirements, analysis and design, implementation and testing activities so as the system grows and requirements change, the system in development is customized to accommodate these changes. The main merit of iteration in USDP the ability to allow change by assuming that requirements may change as the system is being developed. So unlike other processes USDP allow for system revision during development.
At each phase there are related set of activities with a purpose and specific results, called workflows. Work flow defines activities that are grouped that are often performed together to produce a specific result. The core USDP workflows are:
Business Modeling: here current bottlenecks in the organization are identified and likely feasible solutions identified. The organization dynamics and structure where the system is to be deployed is understood.
Requirements: here what the system is to do is established by the customers and stakeholders. System scope within the organization is defined. The cost and time to develop the system is outlined.
Analysis and Design here requirements are transformed are designed into the prospective system. While ensuring the design matches the implementation environment. The system robustness is evolved.
Implementation: unit testing is done in this workflow and then units are merged to form a complete executable system. Implement the design elements by integrating different mini-projects to form an executable system.
Test: aims to find defects in the software and ensure requirements have been implemented appropriately. Find faults in the developed software and validate software products functions as designed.
Deployment: the software is made available to the users.
Supporting workflows: these outline how the software developed will be managed in its domain environment or the ergonomics of the developers. These are:
Configuration & Change Management: identifies configuration items and restricts changes to the items. It audits changes made to the items. It also defines and manages configuration of those items.
Project Management: here risk is managed staffing aspects are considered and project monitored.
Environment: gives the guidelines of the software development environment the processes and tools.
Through iteration cost effective versions of software can be developed if there are cost strains to develop large costly software. Iterations at the 4 phases vary, at inception phase the business modeling is more concentrated than at construction phase.
2.4 USDP and OMT is Object Oriented Techniques but OMT is methodology by itself with its own processes while USDP is method/process. USDP is not an independent methodology like OMT. The major advantage of modeling my web based system processes with USDP over OMT is iterations aspect. Where I make changes to the system when requirements change during development. Thus the system grows as it is being developed. OMT and USDP systems are modeled in Unified Modeling Language. OMT concentrates more on system analysis and design phases leaving out implementation and testing. But USDP is flexibility allow testing and mini implementation from the mini-projects developed, from Inception to Transition. Thus OMT can’t be relied to deliver stable systems fully tested and good enough for implementation. Scholars James Rumbaugh (OMT), Grady Booch (Object Oriented Development) and Jacobson (Object Oriented Software Engineering) combined and developed USDP. That explains why OMT models like USDP share some object concepts.
USDP as a process to organize software development is my preferred method for software development process due to its flexibility and its iterative nature. This is because in the process of doing my project, user requirements may be dynamic and thus I would need to mirror my system to changing requirements. USDP accommodates changing requirements. For this project the succeeding chapters will be determined by the USDP process starting from inception to transition.
Chapter 3: Literature Review
The purpose of this literature review is to discuss the various Software Development Methodologies currently documented, and their processes and modeling language. In addition I will discuss and critique the views of the various scholars who conceived those methodologies and why I prefer using for this project an Object Oriented Methodology like Unified Software Development Process USDP over structured methods..
3.1 Overview: The rising need for software applications in today’s world has lead to explosion in the area of Software Development today. In developing software it’s critical to understand there are plans, procedures and models behind well developed quality software. Those plans and procedures and models fall under the cover software development methodologies. Two common software methodologies today are:
- Structured System Analysis and Design Methodology (traditional)
- Object Oriented and Analysis Methodologies
According to (Rentsch91) Object Oriented Methodologies are the latest in the market while, structured approaches were widely used during the 70’s. Although both methodologies focus on developing fully working complex software systems, their approach to development, process and modeling is different. Structured approach ends up with algorithmic models that show data flowing from one process to another. However in Object Orientation the system architecture is centered on a system with classes that have objects, and how these objects in various classes interact with each other.
3.2 Structured Methods versus Object Oriented Methods
Here I will evaluate Structured Methods and Object Oriented methods by evaluating the key aspects critical to success of whole software development process. The scholars views of the methods and my views too.
Proper Problem Definition: An argument by scholars (Whitten, Bentley Dittman 2001; PageJones, 1988) on structured method models approach is that Data flow models are convenient for describing the problem domain not solution domain. Solution Domain is described by different model sets like structured charts. That means transition from one DFD model to another can result in a gap between analysis and design. Bridging that gap is a problem with structured methods. But Object Oriented Methods proponents (Booch, Rumbaugh, Jacobson, 1999) give thumbs up to problem and solution domain description due to iteration and incremental development.
Modeling Consistency Scholars argued for consistency in Object Oriented Methods where same model sets are used to describe both problem and solution domain. Hence there is seamless transition from analysis to design. A view I support since in Object modeling like in using Unified Modeling Language throughout a process there is uniformity reducing confusion. The unity of models in Object Oriented Methods is achieved through migration of object oriented programming concepts to object-oriented design (OOD) then to Object Oriented Analysis (OOA).
Methodology Robustness Both structured and object oriented methodologies have collective critics. Larman (1998) on structured approaches argues that functional decomposition leads to procedural software architecture. For me most structurally developed softwares are inflexible to dynamic user requirements. Unlike softwares developed in object orientation methods like USDP which are not strictly procedural but produce a robust software application. While Ourusoff (2004) argues that Object Oriented Analysis is solution rather than problem oriented. My view differs with Ourusoff view because in an Object Oriented Process like USDP in elaboration where analysis occurs, the software architecture prototype can’t be developed if problem definition was poorly. In addition even if the problem was initially poorly defined it can still be revised redefined due to iteration aspect in USDP.
Process/phase Modeling In Structured Methods like traditional waterfall model phases from analysis to maintenance there is the issue of inflexibility where once a phase is done with its not revised. Or having requirements revised incase new ones come up. In the case of Object Oriented Methods like Dynamic Systems Development Method (DSDM 2003) and Unified Software Development Process (Jacobson, Booch, Rumbaugh, 1999) there is iterative-incremental approach where there is flexibility in revising phase requirements. I view object oriented methods better for project phasing and provide a comprehensible documentation for end users with little understanding of Object Orientation, due to excellent modeling of the problem domain.
User Acceptance Criteria: The objective of the stakeholders in software development is to have the software meet the pre-specified requirements. One way of having that objective fulfilled is by ensuring the software developed meets the user requirement. One way ofhaving a software meeting that criteria is ensuring user requirements are defined well and if not initially well defined, which is why agile and iterative development are critical due to their people centric viewpoint. Rumbaugh (91) argues that although Object Oriented Methods support reuse of modules from previous designs reuse should not be forced. Reuse is only applicable when a current problem domain matches the previous problem domain in design. My view is the concept of reuse should not overshadow the new problem domain requirements even if the previous and current problem domain matches. User requirements should take priority. Implementation/Transition: After the software development is complete, the issue of implementation comes up. While in an Object Oriented Method like Unified Software Development Process (USDP) there are mini projects in phases. In structured approach like SSADM the final software development implementation occurs when the whole cycle is done. In USDP there are mini-software projects which in my opinion mean that functional software can be available. However (Jacobson 1995) structured approach is rigid and can only produce software once the lifecycle is done.
3.3 Recommendations/Conclusion: The goal of every system developer is to come up with a system that meets the requirements regardless of the methodology used. However it’s critical to understand that the end users will interact with the system when complete. So it’s critical to involve them in the development process notjust at feasibility stage like many structured approaches, but also as the software is being developed. Unified Software Development Process is end user considerate because at each phase if new users needs are detected. Then the system being developed can be revised and such user needs wired into the system. This is why the concept of iteration is critical to have in any methodology. My recommendation would be, for structured approaches like SSADM or Traditional Waterfall, iteration and incremental concept of software development should be wired into such terribly rigid methodologies.
Chapter 4: Inception
At Inception Phase I will establish the business viability of the web based booking system proposed. Then model a partial Use Case of the proposed system with the various actors.
Analyze current booking problems and how the proposed web system might solve them.
4.1 Business Modeling The current problems in the booking department at Dilemma Counseling and propose likely solution(s) in the target organization.
4.1.1 Booking Department
The booking department registers and schedules client(s) sessions with the counselor(s). The problem in Dilemma Counseling is how to organize and schedule their bookings. Results of current booking system are multiple bookings resulting in clashed sessions, and lost booking records resulting to client loss of confidence and time wastage.
4.1.2 Activity Diagram of Current Booking and Counseling System
Client bookings clash when two or more booking secretaries book a client at the same time without informing each other. After booking and payments are made, the client gets counseled and after counseling some follow up, to track counseled client progress is planned. The current operational process is illustrated in the activity diagram below.
illustration not visible in this excerpt
The diagram next page represents the manual form used in the booking department to booking a counseling session. It’s filled manually by booking secretary or clients. Then its records are keyed in a Microsoft Excel worksheet.
Dilemma Counseling Services Booking Form
illustration not visible in this excerpt
The proposed web booking system will be used by clients to book counseling session by registering themselves online. That way, clients will be handled on basis of first to register and pay first to be counseled.
4.2 Requirements: Dilemma Counseling, faces problems with poor booking system, which results in multiple bookings, client follow up after counseling is problematic due to distance. Dilemma Management wants to pioneer a system that allows clients progress to be tracked real time online. So the system I propose to progressively build, must meet these requirements (booking problem and client follow up) or new requirements.
4.2.1 Requirements Modeling: The web based booking system should eliminate the problems of session scheduling since client(s) book online and the details are saved in the database as they occur. The booking department then distributes client problems to various counseling departments. Follow up of counseled clients’ progress to be facilitated through a secure chat interface.
Brief Requirements Explanation
A client enters his personal details online like contacts and name. Then submits the problem on the post problem interface this reserves a session. Payment is made as per instructions posted on the website. Via the bank Μ-Pesa or Sokotele which are money transfer services offered by Safaricom and Zain mobile phone service providers.
The booking staff calls to inform client(s) when they have the counseling session.
After Counseling, the client is informed when they can interact with a counselor online to track his recovery progress via a secure chat room. The Booking Staff can book clients remotely via secure staff login interface.
4.2.2 Preliminary Use Case Descriptions
Bookings: use case will capture client personal data. The client will keys his details on the web interface and submit them. This indicates his interest in being counseled and reserves space for him. Details are saved to bookings master file.
Post Problem; after the user reserves a session, he is redirected to the next interface where he posts his problem and clicks submit. This gives counselors time to examine the problem in advance.
Book Client use case represents the interface the booking secretary may use to book client(s) online by remotely logging in, regardless of his/her location.
Follow Up: This use case allows a counseled client to have his/her progress followed up.
4.3 Requirements Dilemma Clients and staff get the idea ofhow the web booking system will operate. The departments the proposed system will affect once implemented. Come up with the right system requirements i.e. the right hardware and software, the ergonomics, liaising with credible hardware-software and internet providers and designing user-friendly interfaces.
4.3.1 Requirements List
The requirements’ list below illustrates the realized Use Cases so far and their descriptions in the 1st iteration for requirements.
illustration not visible in this excerpt