Project Development Approach And Justification

Project Development Approach And Justification To solve actual problems in an industry setting, software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods and tools layers and generic phases. This strategy is often referred to as process model or a software engineering paradigm or project development approach. A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. Our software is based on Rapid Application Development (RAD) Model. This software development approach is as described as below. Rapid Application Development Model RAD model is an incremental software development process model that emphasizes an extremely short development cycle. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within short time periods (60-90 days). RAD approach encompasses the following phases: Business Modeling: The flow of information among business functions is modeled in such a way that answers following questions: What Information drives the business? What Information generated? Who generates it? Where does Information go? Who Process it? Data Modeling: The flow defined as part of business modeling phase is refined into a set of data object that are needed to support the business. Data Modeling answers a set of specific questions that are relevant to any data processing application. It enables software engineer to identify data objects and their relationship using a graphical notation. C:Documents and SettingshiralsMy DocumentsMy Picturesuntitled.bmp Figure 2. RAD Model (Rapid Application Development Model) Process Modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function processing description s are created for adding, modifying, deleting or retrieving a data object. Application generation: RAD process works to reuse existing program components or create reusable components. Testing and turnover: The RAD process emphasizes reuse; many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised. Advantages of RAD Model: Emphasizes an extremely short development cycle Fully functional system within very short time periods Drawbacks of RAD Model: Like all process models RAD approach has drawbacks: For large but scalable projects, RAD requires human resources to create the right number of RAD teams. RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much-abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail. Not all type of applications are appropriate for RAD. If system cannot be properly modularized, building the components necessary for RAD will be problematic. RAD is not appropriate when technical risks are high. Weeks Months Week l Week 2 Week 3 Week 4 1st Month 1)Orientation program 2)Introduction session 3)Overview of training training Program 4)Introduction to system setup 5)ISO introduction 6)Study of ACTL intranet sites 1) Seminar on ACTL coding standards 2) Database standards and practices. 3) Implementation of demo project named Inventory Management System 1) Testing of demo project named Inventory Management System 2) Lecture on quality assurance 3) Lecture on SDLC 4) Introduction to CRS 1) Study Project definition and requirement analysis of proposed system 2) Data flow analysis of proposed system 3) Decided the software process model for the proposed System. 4) Prepare required diagrams. 2nd Month 1)Learn how JQuery works 2)Study about CRS Restaurant modules 3)Database design 1) Study about amenities module 2) Implement amenities module 3)Testing of created module 1) Study about policy module 2) Implement policy module 3)Testing of created module 1) Study about promotion module 2) Implement promotion module 3)Testing of created module 3rd Month 1) Study about Servings module 2) Implement Servings module 3)Testing of created module 1) Study about Cuisine, Hall, Price List module 2) Implement module 3)Testing of created module 1) Study about booking , Cancelation , Stop Sales module 2) Implement of it 3)Testing of created module 1) Study of Event, Loyalty, User module 2) Implement Events, Loyalty module 3)Testing of created module 4rd Month 1) compliance, Roles , Themes module 2) Implement module 1)Testing created module Report Development 2)Integration of all modules 1) Integration testing 2) Add facility of multi lingual facility 1) Test system on different browsers. 2) Solve Issues. Figure 2.2 Project Planning Milestones: Every task or group of tasks should be associated with project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved. Project Milestones include completion of some defines tasks in defined time limits. The milestones associated with this project are shown below: Study of ACTL Framework JQuery First milestone includes study of ACTL framework, SDLC, study of JQuery documents. JQuery documents includes JQGrid, JQuery Wizard, JQuery Validation, Menu, JQuery Date picker, etc., Database coding standards, query optimization, etc Project planning Scheduling Second milestone includes analysis of project and designing. Then we have started coding to develop first prototype which includes Servings Halls. Cuisine Items setup also includes setup of Items and based on selection of Cuisine, Finally all these modules are debugged and tested. Development of various modules Third milestone includes developing price list module, stop sell module, search booking module. Item Price List module includes setup of rates for different items hall wise. Booking search includes guest searching. Also these modules are debugged and tested. Development continued Fourth milestone includes developing reports module, business setup module, compliance module, etc. These all modules are again tested and reviewed. Testing and Documentation Fifth milestone includes the integration testing and documentation. Deliverables: Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product (e.g., the design of a module) or a part of a work product. Work products are often combined in deliverables. They are delivered at end of some major phase such as specification, design etc. Deliverables for this project are shown below: Project Specification It includes the requirement analysis and specification of each module to be developed. It includes description of each module containing what that module does, how it interacts with another module, what is input to that module and the outputs from that module. Project Design It includes structural design for each module. Design is used for better understanding of each modules functionality and interface. Designing consists of many diagrams which help us to view a system as a whole. Developed Product It is the working product or prototype delivered to customer. Documentation It includes some facilities to help the customer while using this project. Roles: After careful review of requirements, this project requires following different modes for interaction: programming mode, test mode, monitoring mode, and troubleshooting mode. Therefore, roles can be defined as programmer, tester, monitor, and troubleshooter. Here we are three peoples in our team. We all play these four roles as per requirements of project and as per our scheduling. Project Managers role is to review the project and suggest the improvements to be done. Responsibilities: Every task that is scheduled is assigned to a specific team member. Each members responsibility is to develop the assigned module, test it and troubleshooting for that module. Resources: The first step in building the project schedule is to identify the resources required to perform each of the tasks required to complete the project. A resource is any person, item, tool, or service that is needed by the project that is either scarce or has limited availability. The project could include computer resources (like shared computer room, mainframe, or server time), locations (training rooms, temporary office space), services (like time from contractors, trainers, or a support team), and special equipment that will be temporarily acquired for the project. One or more resources must be allocated to each task. To do this, the project manager must first assign the task to people who will perform it. For each task, the project manager must identify one or more people on the resource list capable of doing that task and assign it to them. Once a task is assigned, the team member who is performing it is not available for other tasks until the assigned task is completed. While some tasks can be assigned to any team member, most can be performed only by certain people. If those people are not available, the task must wait. In our team each and every member is assigned specific modules. Resources required by these modules are also allocated to him/her only. Dependencies: Once resources are allocated, the next step is to identify dependencies between tasks. A task has a dependency if it involves an activity, resource, or work product that is subsequently required by another task. Dependencies come in many forms: a test plan cant be executed until a build of the software is delivered; code might depend on classes or modules built in earlier stages; a user interface cant be built until the design is reviewed. It is the project managers responsibility to work with everyone on the engineering team to identify these dependencies. The project manager should start by taking the each module and adding dependency information to it: each task in the selected module is given a number, and the number of any task that it is dependent on should be listed next to it as a predecessor. Figure 2.3 shows the four ways in which one task can be dependent on another. Figure 2.3: Dependency among Modules We have also identified dependencies among the modules and sub modules in our project. Then we have divided our work as per dependencies. Schedule Representation Software project scheduling is an activity that distributes estimated efforts across the planned duration by allocating the effort to specific software engineering tasks. Time Line Chart (Weekly) 1st February To 29th February Week 1 Week 2 Week 3 Week 4 Work Task Introduction to CRS Study Project Definition Analysis Analysis of Amenities Module Analysis of Policy Module Milestone Implementation of Amenities Policy Module Figure 2.4: Project Schedule Representation Work Task Week 4 Week 3 Week 2 Week 11st March To 29th March Testing of developed modules Servings, Cuisine, Halls Implementation of price list, Bookings, stop sell, Testing of developed modules Loyalty, Events Analysis of multilingual Milestone Implementation of Search booking Stop sell Module Work Task Week 4 Week 3 Week 2 Week 11st April To 26th April Testing of developed modules Analysis of Compliance Module Implementation Testing of Compliance Module Integration Testing Solve Issues Creating Themes Multi lingual Milestone Implementation of CRS RISK MANAGEMENT It is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. Project Risks are risks, which affect the project schedule or resources. Product Risks are risks, which affect quality or performance of the software being developed. Business Risks are risks which affect the organization developing or procuring the software. In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice this process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss vs. a risk with high loss but lower probability of occurrence can often be mishandled. Risk Identification Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.) By identifying known and predictable risks, the project manager takes a first step towards avoiding them when possible and controlling them when necessary. There are two distinct types of risks Generic risks and Product-specific risks. Generic risks are a potential threat to the project and Product-specific risks are those that can be identified by only those with clear understanding of the technology, the people and the environment that is specific to that project. Possible risks involved in developing Central Reservation System are technical risks and project risks. First risk Central Reservation System is totally dependent on ACTL Framework. Second risk is that our system needs to be integrated to booking engine via Dxchange middleware that uses XML format data as communication standard . Third risk is associated with authorization; if in the software the anonymous or wrong user is authorized or assign role by mistake then he may do changes that cause the system in dangerous mode. We are planning to give multilingual co-branding system. The risk is associated with time period, the degree of uncertainty that project schedule will be meet, maintained and that the product will be on time. Project Risk includes personnel (staffing and organization) risk and schedule risk. Currently our team size is 3. We can follow our schedule as per planning. If team size gets reduced then schedule and planning must be changed. Risk Analysis Risk analysis = Risk Assessment + Risk Management + Risk Communication. Risk Assessment:- It involves identifying sources of potential harm, assessing the likelihood that harm will occur and the consequences if harm does occur. Risk Management:- It evaluates which risks identified in the risk assessment process require management and selects and implements the plans or actions that are required to ensure that those risks are controlled. Risk Communication:- It involves an interactive dialogue between stakeholders and risk assessors and risk managers which actively informs the other processes. There are two points to keep in mind when analyzing risk: Where is the risk? How significant is the risk? By analyzing the identified risks we have the following conclusion. The probability that algorithm risk becomes reality is very high. We have to study and implement JQuery components. So there is possibility that some of the components cannot fit into current structure. Without these components our current system can run efficiently but either we have to change our desired component. Risk Planning Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories: Risk Avoidance It includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting the risk may have allowed. To avoid the risk also avoids the possibility of earning profits. Risk Reduction It involves methods that reduce the severity of the loss. Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration. A current trend in software development, spearheaded by the Extreme Programming community, is to reduce the size of iterations to the smallest size possible, sometimes as little as one week is allocated to an iteration. Risk Retention It involves accepting the loss when it occurs. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much. Risk transfer It means causing another party to accept the risk, typically by contract or by hedging. Insurance is one type of risk transfer that uses contracts. Other times it may involve contract language that transfers a risk to another party without the payment of an insurance premium. Liability among construction or other contractors is very often transferred this way. On the other hand, taking offsetting positions in derivatives is typically how firms use hedging to financially manage risk. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group. The planning by which the identified risks for this project are handled is described as following: We have planned to build sample application in ACTL Framework so all team members can be familiar with framework. We planned to use OTA standard to communicate with booking engine. We have also planned to use compliance driven system so even if a user is assigned a role accidently then also users changes need to be approved by super administrator. ESTIMATION Effective software project estimation is one of the most challenging and important activities in software development. Estimation is one of the cornerstones of effective project planning: effective project planning and control is not possible without a sound and reliable estimate. Under-estimating a project leads to under-staffing it (which often results in staff burnout), under-scoping the quality assurance effort (running the risk of low quality deliverables), and setting too short a schedule (resulting in loss of credibility as deadlines are missed). This negatively impacts staff productivity, product quality, customer relationships and overall credibility. Conversely, overestimating a project can be just as detrimental. Since most projects expand to fit their estimated schedule, allocating appropriate resources to future projects can quickly become an issue, creating scheduling bottle necks and planning difficulties. Good software estimation and planning goes beyond tools, techniques and processes. Its also about the right attitude, understanding and mutual expectations not just from the software developers but also from senior management. When we understand together what can be done, what has been done, and what is being put before us, we can successfully plan projects to make them more predictable. A sound estimate starts with dividing project in some phases. Each phase is that, if completed, will produce the final product. There are many ways to decompose a project into tasks. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, etc.), or by some combination of the two. Now the team must create an estimate of the effort required to perform each task. The most accurate estimates are those that rely on prior experience. Team members should review previous project results and find how long similar tasks in previous projects took to complete. Sources of delays in the past should be taken into account when making current estimates. No estimate is guaranteed to be accurate. People get sick or leave the organization; teams run into unforeseen technical problems; the needs of the organization change. The unexpected will almost certainly happen. Therefore, the goal of estimation is not to predict the future. Instead, it is to gauge an honest, well-informed opinion of the effort required to do a task from those people in the organization who have the most applicable training and knowledge. Effort Estimation Software costs and effort estimation will never be an exact science. Too many variables human, technical, environmental, political can affect the ultimate cost of software and effort applied to develop it. However, software project estimation can be transformed from a black art to a series of systematic steps that provide estimates with acceptable risks. To achieve reliable cost and effort estimates, a number of options arise: Delay estimation until late in the project Base estimates on similar projects that have already been completed. Use relatively simple decomposition techniques to generate project cost and effort estimates. Use on or more empirical models for software cost and effort estimation. We are adapting following criteria to estimate the effort. Step 1: We are computing the count total which will be used to define the complexity of a project. You will do that by completing the Figure 2.5. Top of Form Measurement Parameter Count Simple Average Complex Total Number of user inputs X 3 4 6 = Number of user outputs X 4 5 7 = Number of user inquiries X 3 4 6 = Number of files X 7 10 15 = Number of external interfaces X 5 7 10 = Count Total Figure 2.5: Table to compute Count Total Step 2: We are finding the complexity adjustment values based on responses to the questions shown in Figure 2.6. Question 0 1 2 3 4 5 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational environment? 6. Does the system require on-line data entry? 7. Does the on-line data entry require the input transaction? 8. Are the master file updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11. In the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? Total fi Complexity Weighting Factors (0 = No influence, 1 = Incidental, 2 = Moderate, 3 = Average, 4 = Significant, 5 = Essential): Figure 2.6: Table to compute Complexity Adjustment Values The Function Points is: (FP=Count Total + {0.65+0.01*(Efi)}) Step 3: We are finding LOC (Lines of Code), and we do this by choosing a programming language that we will use when developing a project. Figure 2.7 shows LOC/FP for different programming languages. Programming Language LOC/FP (average) Select Assembly Language 320 C 128 COBOL 105 Fortran 105 Pascal 90 Ada 70 Object-Oriented Languages 30 Fourth Generation Languages (4GLs) 20 Code Generators 15 Spreadsheets 6 Graphical Languages (icons) 4 Figure 2.7: LOC/FP Values for Different Programming Languages So LOC/FP for our project is Step 4: Final Step is to select complexity of the software project. Figure 2.8 is used to calculate effort and duration of the project. Software Project ab bb cb db Select Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 Figure 2.8: Table to compute Effort and Duration From Figure 2.8 calculated effort and duration are: Effort (E) = ab(KLOC)bb = Duration (D) = cb(E)db = Cost Analysis: A cost-benefit analysis is necessary to determine economic feasibility. The primary objective of the cost-benefit analysis is to find out whether it is economically worthwhile to invest in the project. If the return on the investments is good, then the project is considered economically worthwhile. Cost-benefit analysis is performed by first listing all the costs associated with the project. Costs consist of direct costs and indirect costs. Benefits can be broadly classified as tangible benefit and intangible benefits. Tangible benefits are directly measurable and intangible are not. The sum of all costs is compared with the sum of all the savings (tangible and intangible). It is not always easy to assign money value to intangible benefits. It is arrived at by discussion amongst users of the system. Figure 2.9 shows general cost associated with project. Procurement Cost Installation cost for installing supporting software like Microsoft Office, Microsoft Visual Studio etc. The company already has the license for this software. Project Related Cost Cost of Data Collection for System Analysis. Cost of preparing Documentation. Cost of Development Management. Cost of Organization Resources. Ongoing Cost System Maintenance cost. Depreciation cost. Figure 2.9: Cost Representation Estimation of Cost is not provided to us as it is against the policy of Avani Cimcon Technologies Ltd. and due to some security reason.