PPSP

Submitted By: Charith Devaka Sooriyaarachchi Shanil Fernando Maheeka Jayasuriya CB003344 CB002723 CB003346
Submitted To: Mr. Shanaka de Silva
Module Title and Code: CE00003-2 Principles and Practices in Software Production
Intake Code: HF09B1SE / HF0981MM
Assignment Title: Delta Entertainment Company Online System
Date Assigned:
Date Due: 12th February 2010
Asia Pacific Institute of Information Technology
TABLE OF CONTENTS
TABLE OF CONTENTS................................................................................................................ 1 LIST OF FIGURES ........................................................................................................................ 5 LIST OF TABLES .......................................................................................................................... 6 Chapter 1 ......................................................................................................................................... 7 PROJECT BRIEFING .................................................................................................................... 7 1.1 Introduction ...................................................................................................................... 7
1.2 Problem Background ............................................................................................................ 9 1.3 Proposed Solution ............................................................................................................... 10 Chapter 2 ....................................................................................................................................... 11 SCHEDULE PLANNING ............................................................................................................ 11 2.1 Gantt Chart .......................................................................................................................... 11 2.2 PERT Chart (Activity Network) ......................................................................................... 12 2.3 Workload Matrix................................................................................................................. 13 Chapter 3 ....................................................................................................................................... 15 SELECTION OF METHODOLOGY........................................................................................... 15 1.1 Identification of methodologies .......................................................................................... 15 2.2 Selection of Methodology ................................................................................................... 33 2.3 Justification of the chosen methodology............................................................................. 37 Chapter 4 ....................................................................................................................................... 39 PROJECT PLANNING CONTROL ............................................................................................ 39 4.1 Configuration Management (scm/cm) ................................................................................ 39 4.2 Software Quality Assurance Plan ....................................................................................... 40 Principles and Practices in Software Development 1
Asia Pacific Institute of Information Technology Quality Plan........................................................................................................................... 42 4.3 Risk Management Plan ....................................................................................................... 45 4.4 Documentation Standards ................................................................................................... 46 Types of documents: ............................................................................................................. 46 Document structure ............................................................................................................... 50 4.5 Programming Standards ...................................................................................................... 52 Chapter 5 ....................................................................................................................................... 54 PROJECT MANAGEMENT ........................................................................................................ 54 5.1 Introduction to Software Project Management ................................................................... 54 Chapter 6 ....................................................................................................................................... 64 PROJECT RISK MANAGEMENT PLAN .................................................................................. 64 6.1 Risk Management Concepts ............................................................................................... 64 6.2 Risk Management Plan ....................................................................................................... 69 Chapter 7 ....................................................................................................................................... 73 COST ESTIMATION ................................................................................................................... 73 7.1 Techniques for Cost Estimation .......................................................................................... 73 7.2 Cost Estimation ................................................................................................................... 77 Chapter 8 ....................................................................................................................................... 79 REQUIREMENT ANALYSIS ..................................................................................................... 79 Chapter 9 ....................................................................................................................................... 89 PROCESS MODELLING ............................................................................................................ 89 9.1 Context Diagram ................................................................................................................. 89 9.2 Level 0 DFD........................................................................................................................ 90 9.3 Level 1DFDs ....................................................................................................................... 92 9.4 Process Specification ........................................................................................................ 100 Principles and Practices in Software Development 2
Asia Pacific Institute of Information Technology Chapter 10 ................................................................................................................................... 103 DATA MODELLING................................................................................................................. 103 10.1 Entity Relationship Diagram........................................................................................... 103 10.2 Entity Life History .......................................................................................................... 104 Chapter 11 ................................................................................................................................... 108 DATA DICTIONARY................................................................................................................ 108 11.1 External Entities .............................................................................................................. 108 11.2 Process ............................................................................................................................ 109 11.3 Data Stores ...................................................................................................................... 114 11.4 Data flows ....................................................................................................................... 116 Chapter 12 ................................................................................................................................... 121 DESIGN PRINCIPLES AND CONCEPTS ............................................................................... 121 12.1 Design Principles and Concepts...................................................................................... 121 Chapter 13 ................................................................................................................................... 132 ARCHITECTURAL DESIGN.................................................................................................... 132 13.1 Overall Architecture........................................................................................................ 132 13.2 Site Map (Site diagram) .................................................................................................. 134 Chapter 14 ................................................................................................................................... 136 INTERACTIVE SCREEN DESIGN .......................................................................................... 136 Chapter 15 ................................................................................................................................... 150 REPORT DESIGN...................................................................................................................... 150 Chapter 16 ................................................................................................................................... 157 PROGRAMMING ENVIRONMENT ........................................................................................ 157 Chapter 17 ................................................................................................................................... 158 TESTING .................................................................................................................................... 158 Principles and Practices in Software Development 3
Asia Pacific Institute of Information Technology 17.1 Test Plans for User & Guest Input/output....................................................................... 158 17.2 Test Plans for Administrator & Staff Input/output ......................................................... 166 REFERENCES ........................................................................................................................... 169 APPENDICES ............................................................................................................................ 171 A. B. C. User Manual ................................................................................................................. 171 Questionnaire ............................................................................................................... 182 Questionnaire Summary ............................................................................................... 185
Principles and Practices in Software Development
LIST OF FIGURES
Figure 1: Waterfall model ............................................................................................................. 17 Figure 2: Incremental model ......................................................................................................... 18 Figure 3: Rapid Application Development ................................................................................... 20 Figure 4: Prototyping .................................................................................................................... 22 Figure 5: Spiral Model .................................................................................................................. 24 Figure 6: Agile Development Methodology ................................................................................. 29 Figure 7: Agile Development Methodology ................................................................................. 30 Figure 8: Development process..................................................................................................... 41 Figure 11: Planning Process.......................................................................................................... 59 Figure 12 : Risk management process .......................................................................................... 65 Figure 13: Context Diagram ......................................................................................................... 90 Figure 14: DFD 0 .......................................................................................................................... 91 Figure 15 : DFD 1.0 ...................................................................................................................... 92 Figure 16: DFD 2.0 ....................................................................................................................... 93 Figure 17: DFD 3.0 ....................................................................................................................... 94 Figure 18: DFD 4.0 ....................................................................................................................... 95 Figure 19: DFD 5.0 ....................................................................................................................... 96 Figure 20: DFD 6.0 ....................................................................................................................... 97 Figure 21: DFD 7.0 ....................................................................................................................... 98 Figure 22: DFD 8.0 ....................................................................................................................... 99
LIST OF TABLES
Table 1: Roles and responsibilities of stakeholders in risk management ..................................... 67 Table 2: Cost Estimating Factors .................................................................................................. 77 Table 3: Function point calculation .............................................................................................. 78
Chapter 1 PROJECT BRIEF ING

1.1 Introduction
Delta Entertainment Company (DEC) is a company that sells and rents videos, music and games to customers. DEC is already a profitable company and is growing. However the competition from other existing and emerging competitors has become a challenge for DEC. therefore it has prompted DEC to maintain a better and unique service than the competitors. They are constantly considering better ways to fulfill customer needs. This is why they have requested for a new and better system to keep their position in industry and also to broaden it. Task The task of this system is to develop a system for Delta Entertainment Company, so that, the company will be able to provide better service to the customers and also broaden its service. The system will allow customers to purchase items, rent items and also provide feedback to obtain a better service from the company. The system to be developed is an online system, which enables to allow worldwide customers to make deals with the company. Also it enables the customers to provide feedback about the items available for purchase and rent and also their likes, dislikes and preferences easily. This way it can widen its service and also easily obtain customer feedback to grow and improve its service. The final outcome of this project is to prove or disapprove, that such an information system will improve customer satisfaction and lead to increased revenue and to a potentially increased market share. Scope The new system will be a web application where c ustomers across the world can log to it and rent videos, music and games, and even purchase them. Also the customers will be able to state Principles and Practices in Software Development 7
Asia Pacific Institute of Information Technology in the application their likes, dislikes and preferences and view reviews about these items made by other customers. The customers can view the whole inventory of the items available at DEC. They can make a request for a rent and the item is delivered to home by the company. They can return it by posting it back. Also when an item is purchased, he can pay for it using his account or using his PayPal account and get the item delivered straight to his home. To rent items, the customer has to register through the company website. The company will make communication with the customer using his email contact and also through the website at the customers home page. The company will store about the customers preferences and make notifications to him about the appropriate items. Also the customer can provide the company with his feedback. Children also can create accounts under parents supervision. This is a very tricky and important feature in this system. This way, the company will be able to provide a better user-centred and user-friendly service to the customers.
Objectives Objectives of the proposed system is as follows, 1. Customers must be able to buy videos, music and games from the company 2. Registered customers must be able to rent videos, music and games from the company 3. The customers must be able to submit structured and unstructured comments about movies, music and games they bought or rented 4. Customers must be able to make requests for new products for sale and rent 5. Customers must be able to check on due dates for customers outstanding rentals 6. Customers must be able to extend a rental without penalty, for a minor fee to be applicable when the item is returned 7. Customer must be able to review the inventory of items carried in store 8. Parental control method, so that parents can monitor their childrens accounts (both purchases and rentals)
1.2 Problem Background
Delta Entertainment Company (DEC) needs to widen its service as a video, music and game rental and purchase system. is a company that sells and rents videos, music and games to customers. DEC is already a profitable company and is growing. However the competition fro m other existing and emerging competitors has become a challenge for DEC. therefore it has prompted DEC to maintain a better and unique service than the competitors. They are constantly considering better ways to fulfill customer needs. This is why they ha ve requested for a new and better system to keep their position in industry and also to broaden it.
1.3 Proposed Solution
Principles and Practices in Software Development 10
Chapter 2 SCHEDULE PLANNING

2.1 Gantt Chart
2.2 PERT Chart (Activity Network)
2.3 Workload Matrix

Project Briefing Introduction Problem background Proposed solution Schedule Planning Gantt chart PERT chart Workload matrix Activity network Selection of Methodology Methodology description Selection of methodology Justification of the chosen methodology Project Planning Control Configuration Management Software Quality Assurance Plan Risk Management Plan Documentation Standards Programming Standards Communication Mode Project management Project management description Project planning process Resource allocation Cost Estimation Cost estimation description Application of cost estimation Risk Management Risk assessment Risk control Risk identification

Risk analysis Risk prioritization Requirements Analysis Requirements analysis description Application of requirements analysis Process Modeling Context Diagram Level 0 DFD Level 1 DFD Process Specification Data Modeling ER Diagram Entity life history Data Dictionary Data flows Data stores Processes Source and Sink Design Principles and Concepts Design principles and concepts description Application of design principles and concepts Architectural Design Architectural diagram System Design Interactive screen design Report design Programming Environment Programming environment explanation Testing Test plan Quality matrices Documentation

Documentation
Chapter 3 SELECTION OF METHODOLOGY

A system development methodology refers to the framework that is used to structure, plan and control the process of developing an information system (Centers for Medicare and Medicate Services, 2008)
There are a variety of system development methodologies that are used in developing an information system. Selecting the most appropriate methodology for a project depends on the project requirements and various technical, organizational, project and team considerations. Below is a description of the different methodologies.
1.1 Identification of methodologies
Waterfall model Waterfall model, sometimes called classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling , construction and deployment, culminating in on-going support for completed software (Pressman R.,2003) This describes a development method that is rigid and linear. This development has a set of distinct goals to be achieved in each phase of development. Only after completion of one stage, Principles and Practices in Software Development 15
Asia Pacific Institute of Information Technology one can proceed to the next stage. In waterfall methodology there are no chances to move to a previous phase to make changes or redo a task. This is most used in situations of making enhancements to an existing system. Waterfall model is a version of Systems Development Life Cycle model for software engineering. Most emphasis is on planning, time schedules, target days, budgets and implementation of entire system at one time. Throughout the project life cycle, a tight control is maintained with extensive written documentation, as well as through formal reviews and approval/sign off by the client and project management before proceeding to next phase (Centers for Medicare and Medicate Services, 2008)
Advantages Most appropriate for supporting less experienced project teams and project managers whose work fluctuate Sequential development steps and strict and adequate documentation and design improves quality, reliability and maintainability of the developing software Scheduled deadlines for separate phases encourages the project to finish on time Progress of the project can be easily measured Conserves resources
Disadvantages Inflexible, slow, costly and weighted due to strict structure and tight procedure No or less chances for iteration of steps (or revision) Totally depends on the early identification and specification of requirements Discourages changes of requirements during project development Problems are not identified until the system testing phase Produce of detailed documents is time consuming
Figure 1: Waterfall model (Source: Pressman R., 2003)
Incremental model Incremental model combines elements of the waterfall model applied in an iterative fashion. The incremental model applies linear sequences in a spread out fashion. Each linear sequence produces deliverable increments of the software. As the first step, a core product is delivered. This core product addresses most of the basic requirements, but most remain undelivered. The core product then undergoes further evaluation and develops the next increment. This is repeated until the product is completed. This each delivery goes through a set of waterfall models.
Figure 2: Incremental model (Source: Pressman R., 2003)
Incremental model, just like prototyping, is iterative in nature. But the difference of incremental model is that it delivers an operational product with each increment. Very useful if staffing is not available for a project. Advantages Potential exists for exploiting knowledge gained in an early increment as later increments are developed Project control is moderate with reasonable amount of written documentation, formal reviews and approval/ sign off from the client and project managers Stakeholders can be provided evidence of the project status Helps to mitigate integration and architectural risks earlier in the project Allows delivery of a series of implementations that gradually becomes more complete as the incremental increases
Asia Pacific Institute of Information Technology Disadvantages When a set of mini-waterfall models are being utilized, there is a lack of consideration to the overall system scenario Since some modules will be completed earlier than others, well defined interfaces are required
RAD model Rapid Application Development (RAD) is an incremental software development methodology that emphasizes a short development cycle. (Pressman R., 2003) RAD is to develop a system of high quality in less time at a relatively low investment cost. The project is broken down into smaller segments which help to reduce risk and ease of change during the development. High quality and speed is achieved by using iterative prototyping, active user involvement, and computerized development tools. The techniques used are; Graphical User Interface (GUI) Builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), 4th generation programming languages, code generators and
object oriented techniques. Workshops or focus groups are used gather requirements fast. Software and modules are re-used. Most of the review meetings and other team communications are kept informal, to speed up the development. This methodology uses an iterative process to develop a system. (Alexandrou, 2010)
Figure 3: Rapid Application Development (Source: Pressman R., 2003)
Advantages Since RAD produces systems quickly and to a business focus, this approach develops systems at a low cost Engenders a great amount of commitment from stakeholders, both business and technical, than waterfall, incremental and spiral models. Therefore, users get a sense of ownership to the system and, the developers gain satisfaction by developing the syste m quickly. Concentrates on essential system elements from the users point of view. Able to rapidly change system design as the user demands Generally produces a dramatic saving in time, money and human effort.
Asia Pacific Institute of Information Technology Disadvantages Needs a sufficient amount of staff to create RAD teams High speed and low cost might lead to lower system quality Danger of misalignment of developed system due to missing information Project may end up with more requirements than needed. (gold-plating) Potential for feature creep, where more and more features are added to the system during development Potential of inconsistency in design within and across the system Potential for violation of programming standards, inconsistent naming conventions and documentation Difficulty to reuse modules for future systems Since some modules will be completed earlier than others, well-defined interfaces are required Not appropriate when technical risks are high(when new applications heavily use new techniques)
Prototyping Prototyping is most appropriate when the general objectives of software are known, but when the details input output and processing requirements are undefined. Prototyping allows the software engineer and the customer to understand the system requirements when the requirements are unclear. Prototyping starts with communication. First the main objectives of the software is identified and also the known requirements. Then the areas that need further investigations are identified. In prototyping, planning and modeling occurs (quick design). This quick design constructs the prototype, which are the software components visible to the end user. This prototype is then deployed and evaluated by the user. This process is repeated until it meets user requirements. Prototype is the mechanism used to identify the requirements. Principles and Practices in Software Development 21
Figure 4: Prototyping (Source: Pressman R., 2003) Advantages Supportive for users who have difficulties in specifying system requirements Improves both user participation in system development and communication among project stakeholders Useful for identifying unclear objectives, developing and validating user requirements Helps to identify confusing or complex functions or missing functions Provides quick implementation of an incomplete, but functional application
Disadvantages Approval process and control is not strict Incomplete or inadequate problem analysis Requirements may change frequently and significantly Identification of non-functional requirements are difficult to document Quick prototyping might result in inflexible design and limit future system potential
Asia Pacific Institute of Information Technology Documentation might be neglected and therefore result in insufficient justification for the final product and inadequate records for future Can lead to poorly designed systems. Can lead to false expectations, customer mistakenly believes that the system is complete , when actually it is not complete and is not functional Iterations of prototyping might increase cost
Spiral model This is a model that combines iterative nature of the prototype model and the controlled and systematic aspects of the waterfall model. This model is generally selected over waterfall for large, expensive, complicated projects. In spiral model, software is developed in a series of evolutionary re leases. During early iterations the release might be a paper model or a prototype. Later, more complete versions are developed. To develop a spiral model, first of all the system requirements must be collected in detail. Then a preliminary design is constructed. Using this design, the first prototype is created. Then, the second prototype is designed. For designing this second prototype, the first prototype is evaluated to identify its strengths, weaknesses and risks. And requirements are again defined for the second prototype, plan the prototype and finally, construct and test the prototype. This process is repeated until final product is met. This model is appropriate for the development of large scale systems and software because, software evolves as the process progresses.
Figure 5: Spiral Model Advantages Risk avoidance is practiced Useful to select the best methodology to follow development of a software project Can incorporate waterfall, prototyping and incremental models to provide guidance as to which combination best fits for the software iteration. Disadvantages Challenging to determine the exact composition of development methodologies to use each iteration around the spiral Highly customized to each project. Thus, it is quite complex Skilled and experienced project managers are required to adapt this model There arent any controls established for moving from one cycle to another. Therefore one cycle might even generate more work for the next cycle No firm deadlines, cycles continue with no termination point
Asia Pacific Institute of Information Technology JAD model This methodology aims the involvement of the client in the design and development of an application. This is accomplished through a series of workshops known as JAD sessions. JAD leads to lead to shorter development times and greater client satisfaction when compared with waterfall model. Anyhow, both models require constant client involvement throughout the development process. (Alexandrou, 2010) In JAD, it is believed that people who do the job and those who are trained for information technology have the best understanding and knowledge about the technology. Therefore the best result is obtained when all groups work together in a project. A JAD p roject can fail by poor communication within the project team, incomplete requirement definitions and lack of survey. Highly structured, well planned meetings are conducted with facilitators, end users, developers, observers and domain experts to identify the key components of the system. Compared with other methods, Basically, JAD is used to develop system quickly. But yet this takes a great deal of time to plan and this is also considered as a rather expensive methodology. Advantages Allows key users to participate effectively When properly used, JAD results in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system Disadvantages More expensive and cumbersome if the group is too large relative to the size of the project
Asia Pacific Institute of Information Technology (Shelly, Cashman and Rosenblatt, 2001) Systems Development Life Cycle The systems development life cycle is a systematic approach to solving business problems . This methodology is often used on large projects as it requires a very long development process. It is expensive and also takes in much effort. There are 6 or 7 stages of the SDLC model. Here, we discuss the 6 step model which is the most popular one. The steps are, 1. Project planning 2. Requirements definition 3. Design 4. Development 5. Integration and test 6. Installation and acceptance These stages are built on one another. Upcoming stage accepts output from the previous stage and produces another output which acts as input for the next stage (Anon, n.d.)
Advantages Lends itself to good control Phase deliverables are well defined Clear checkpoints makes review easy Creates detailed documentation which is valuable for maintenance
Disadvantages Time and cost estimation is difficult Can be very time consuming Requires the requirements to be defined theoretically
(Anon., n.d.)
Agile Methodology Agile methodology addresses three characteristics of software development process. Principles and Practices in Software Development 27
Asia Pacific Institute of Information Technology Difficulty in predicting in advance the software requirements that will persist and will change and difficulty in predicting how customer priorities change as a project proceeds. Difficulty in predicting how much design is necessary before construction is used to prove the design. Because, design and construction should be done hand in hand in order to prove the design models as they are being created. Analysis, design , construction and testing are not as predictable ( from planning point of view)
To overcome this problem of unpredictability in a software project, there must be a methodology that that is adaptable to these rapid changes in project and technical conditions. Therefore, agile methodology is adaptable. But for the project to progress, only adaptability is not enough. It must also follow an incremental adaptation. To accomplish this incremental adaptation, customer feedback is required, so that the adaptations can be made. These increments must be delivered iteratively. This iterative approach enables the customer to evaluate software increments regularly and influence the project adaptations. (Pressman R., 2003) Since this iterative and incremental nature of agile methodologies, every aspect of development requirements, design, etc., is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project from time to time, theres always time to steer it in another direction. This approach greatly reduces development cost and time. Because requirements can be gathered at the same time development of the software continues. This way agile development methodology helps to develop the right product. (Agile Methodology Organization, 2010) Agile process is defined as follows
Figure 6: Agile Development Methodology
(Source: Sudarsan iTech Pvt Ltd, n.d.) 1. Brainstorm Study requirements and define the concept or idea and decide the technologies to be used 2. Design Analyze project requirements and design the software in a series of iterative processes to create working prototypes. Feedback from the customer at this stage helps reduce cost and development time. 3. Development Adapt to changing requirements and constantly change code and architecture to optimize and update softwares internal structure.
Figure 7: Agile Development Methodology (Source: Sudarsan iTech Pvt Ltd, n.d.)
Phases that come under development phase can be described as below 1. Requirements analysis : define business requirements, analyse use cases and analyse architecture 2. Iterations and releases : design detailed iteration, set milestones and release schedules 3. Product design : develop product design, product standards and test plans 4. Product development : focus on change in requirement, development and refactoring 5. Testing : execute test plans track and fix defects/ issues, quality assuarance 6. Deployment : customer feedback, customer acceptance and product release 4. Testing
Asia Pacific Institute of Information Technology At the end of iteration, the working software is delivered. Continuous testing deterministically assesses progress and prevents defects, also decrease the risk of failure late in the project development cycle.
5. Deployment Throughout the entire process, the project team plans, tests and delivers the daily status of the software. As the iteration passes by, the team hits the pace. When all of the modules tested in several iterations and test plans pass, the customer accepts it. (Sudarsan iTech Pvt Ltd, n.d.)
Advantages Agile methodology has an adaptive team which is able to respond to the changing requirements The team does not have to invest time and effort and finally find out, by the time product is delivered, the requirements of the customer has changed Face to face communication and continuous inputs from customer representative leaves no space for guesswork The documentation is crisp and to the point to save time The end result is high quality software in least possible time duration and satisfied customer
Disadvantages In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the project development There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. Principles and Practices in Software Development 31
Asia Pacific Institute of Information Technology Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for new programmers, unless combined with experienced resources.
2.2 Selection of Methodology
Waterfall model Waterfall model is most appropriate for the development of a mainframe-based or transactionoriented batch system. To apply waterfall model, the objectives and the solution must be clear. It is most used for projects that are expensive, and complicated in nature. Also, waterfall model gives best results when applied to a system that has no time hard time constraints. The project requirements ought to remain unchanged and stable throughout the project development. There shouldnt be any immediate need for the implementation. The proposed system is not a batch system and also it is not an expensive and a complicated one. Also this project has a strict time constraint which is why waterfall cannot be adapted for the development of this project. And also the solution ought to be developed quickly. To implement the waterfall model, the implementation shouldnt be hurried, which is not possible in this project, we are given a very small time period, which is not at all enough for implementing waterfall model. However, the objectives and the solution are clear in this project which is one reason waterfall can be adapted. But since more reasons state that it isnt appropriate we havent adapted waterfall model as our system development methodology.
Incremental model Incremental model is most appropriate for large projects where requirements are not well understood or are changing due to external changes, changing expectations, budget changes or rapidly changing technology. Our system is not highly affected from external changes during the development. Also this method is not appropriate because the time is very limited, which is not enough for applying incremental model. To get a productive and accurate product several increments must be performed, which is highly time consuming. Therefore incremental model cannot be applied for the development of this project.
Asia Pacific Institute of Information Technology RAD model RAD model is most appropriate when, when the project is of small or medium scale and of short duration. Also the project scope has to be focused, such that objectives are well defined. The system must not also be complex in nature to gain best results by applying RAD model. Team members have to be skilled both socially and in terms of business. And the developers have to be skilled in using advanced tools. In consideration with our project, this is also of medium scale and is of a short duration. Also the objectives are clearly defined and the scope is also focused. But the problem in adapting RAD in our project is that it requires very high technical skills and tools. These are essential to complete the project with less time. Using these tools is expensive as well. Therefore, this model is not appropriate for the proposed system development.
Prototyping Prototyping is most appropriate when, it is to develop an online system that requires wide amount of user dialog or for a well-defined expert and decision support system and also if the project is large which has many users, interrelationships and functions with unclear objectives.. Prototyping involves user feedback that helps to make changes to the system to build the best solution. Also errors can be identified at a very early stage of the projec t. When considering these factors, prototyping is very much appropriate for our system. But too quick prototyping might result in inflexible design and limit future system potential. Prototyping also neglects documentation, which is not at all appropriate for our project, since it requires a lot of documentation as justifications for the final product. Also with this model it can lead to false expectations, where the system is mistakenly believed to be complete ad functional when it is not. Also when evaluating from one prototype to another, it might limit creativity and new ideas of the developers because they tend to think from the same point of view, which is a great disadvantage of prototyping. Apart from these, developing of several prototypes might be costly. Therefore this model is also not appropriate for our system.
Asia Pacific Institute of Information Technology Spiral model Spiral model is most appropriate for projects where the project team is highly skilled. It can be combined with other methodologies and allows selecting the best model poss ible for the development. This model is appropriate for the development of large scale systems and software because, software evolves as the process progresses. Since our project is not of large scale, there isnt really a need for such a methodology. The problem with spiral model is that it is challenging to determine the exact development methodology to be incorporated in the spiral. This is a quite complex model, where it is very much customized and the adapting to the methodology itself is a hard task. Spiral model doesnt specify a firm deadline which is another reason why it cannot be applied for our project.
JAD model JAD allows the users to participate in the development process effectively. It is also very much appropriate when the developing system highly affects the success of the organization. This factor is true in our project, because the whole organization depends on the system and the purpose of developing the system itself is to improve the success of the organization. But the disadvantage and why it cannot be implemented for our project is that it is a very expensive process.
Systems Development Life Cycle SDLC is a highly structured development methodology. Its phase deliverables are well defined. Also it creates detailed documentation which is a requirement in our system. Therefore it seems appropriate for our project. But the problem with SDLC is that it is very time consuming. Also in the first place, time and cost estimation is also difficult. Also this methodology requires the requirements to be well defined. And SDLC doesnt guarantee that the system will be accepted by the user because no prototyping and user feedback is used. Therefore, SDLC is not appropriate for the development of this project. Principles and Practices in Software Development 35
Asia Pacific Institute of Information Technology Agile methodology Agile methodology follows an adaptive nature which responds to changing requirements in a positive manner. Therefore, the developed product will always meet user requirements. The documentation in agile is also very straightforward and to the point. The final product will be developed in least amount of time possible and has a high usability level, because of proper customer feedback. With the limited time available for our project and since high quality of the product, agile will be the most appropriate methodology to be applied in this project. Normally in agile it is hard to estimate the effort required for large projects, but for this project, since it is not a very large one, estimation would not be difficult. But, however it also have disadvantages. The project requires a considerable amount of resources, especially skilled programmers and experienced management. However it is the best methodology to be adapted to the development of this project.
2.3 Justification of the chosen methodology
As the above section describes, agile is very much appropriate for situations where, there exist a high amount of change in the requirements throughout the project development. Since, our project scope is not fixed, that is within the objectives of the project, we were given the opportunity of making changes to the requirements. Thats the most important idea behind selecting Agile as our system development methodology. Also our group size is only three, which is a small group. Agile is most appropriate for small project groups, which is also a reason to select Agile. Time taken for the development process is also considerably small and ultimately agile provides high quality software. This is very important because of the available time constraint in our project. Agile helps to identify and implement all the tasks to be performed by the system. Therefore, nothing is missed out. The description of the agile methodology and how it can be implemented is discussed above. The system is following a number of iterations in the development phase before reaching the final product. This is why the product is of high quality. It can also allow some phases to be parallel performed in order to reduce the time factor. However, there are two main features in the agile method.
Agile methods are adaptive rather than predictive

Agile welcomes changes to requirements of the system. They try to adapt to the changes and act based on the change
Agile methods are people-oriented rather than process-oriented

The process that is being defined must work well whoever uses it. But agile methods believe that there cannot be a process that will match the skill of the developers, and therefore Agile defines processes to support the development team in their work. According to Miller (2001), some of the reasons to use agile in software development are, Modularity on the development process level Principles and Practices in Software Development 37
Asia Pacific Institute of Information Technology Iterative with short cycles enabling fast verifications and corrections Time- bound with iteration cycles from 1- 6 weeks Parsimony in development process removes all unnecessary activities Adaptive with possible emergent new risks Incremental process approach that allows functioning application building in small steps Convergent(and incremental) approach minimizes the risks People-oriented ( agile processes favor people over processes and technology) Collaborative and communicative working style
All the above reasons apply for our project. We have a modularity development of the software; time bound is about 9 weeks; our system development must be adaptive to changing requirements ; functional application is allowed to be built in small steps; and minimization of risks; collaborative and communicative working style are the main reasons to use Agile in our system development process. Being people-oriented is also very important in this case. Because, we have less technical resources and the group members (people) is the most important and valuable resource we own. Agile supports this idea. With consideration it the above reasons, Agile is justifiab le as the best available methodology for the development of this system.
Chapter 4 PROJECT PLANNING CONTROL

4.1 Configuration Management (scm/cm)
Configuration management is unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system.(Anon.,n.d.)
Configuration management plan is a part of project document, but in small projects we can consider this as separate document. This is describing tasks and methods used to identify configuration through the project. As mentioned above in literature description about configure management this describing the activities involved in controlling, status accounting, auditing and releases management. Roles involve in configuration management and creating of base lines. Team personnel Implementation of Configuration Management process, performing Configuration Product Development Lead Management activities, submit Change Requests Direct and interface with people during projects life cycle
Configuration Management Officer Configuration Control Board Data Management Lead
Coordinate and implement configuration management for the project
To ensure the establishment of the baselines
Coordinate and implementing the data management for the project, schedule and implementing control of project data, provide reports Pfarr, 2007) Principles and Practices in Software Development 39
4.2 Software Quality Assurance Plan
The QA plan should describe the activities and methods used to build a high-quality product by the sensible application of an appropriate process. The plan should indicate the relationships among the quality assurance, testing (or verification and validation), peer review, audit, and configuration management activities. Identify the quality-related tasks to be performed, which are responsible for each, and the target date for completion. Estimate the percentage of project effort or the number of hours planned for quality assurance activities. Incorporate QA tasks into the project schedule and budget. List the personnel responsible for performing identified quality assurance task tasks.
Quality Policy: Users are given the number one priority, through providing an optimal user- friendliness, and innovativeness that attracts them to the system
This will be achieved through the following methods: Responding to customer inquiries as quick as possible Preventing errors from occurring, rather than waiting for reac tion Developing a fully interactive system that makes users comfortable with using it Providing innovative features and ideas Continuing to grow, my improving with change
Objectives of Quality: Objectives are identified in order to keep the focus on the customer, so that at all times, customer satisfaction is met. These objectives are documented and available for all employees and staff so that it is clearly understood by them. Principles and Practices in Software Development 40
Asia Pacific Institute of Information Technology Scope: The website has the scope of not only providing an facility to rent and purchase movie, game and songs. Wes site gives updates about the new DVS arrived.
Developmental processes
Processes in system
Analysis of existing system
Design process
Development process
Testing
Maintenance of system
Figure 8: Development process
The above are the main processes involved in developing the system, and thus it is very important to ensure that these processes are carefully controlled so that the system is developed to the highest of quality.
Quality control This can be achieved through a continuous list of reviews, tests, and inspections that are held throughout the developmental process so that the system meets the requirements in the appropriate time. (Pressman, 2005) Quality control will be achieved in this project through all these measures in order to produce a system of high quality.
Asia Pacific Institute of Information Technology Moreover, to control the quality, surveys will be distributed monthly, to gain feedback on the quality of system. Document control This process handles the changes to procedures, instructions and the operating documents. Staffs are able to give suggestions to implement quality management system documents and can review the changes.
Software Quality Assurance A team is assigned to make sure that the system developed is of the highest quality possible. Quality Plan Quality Requirements System should be user friendly to all Users should feel satisfied with the system and interested to use it to share ideas with friends The response should be provided quickly Performance and efficiency should be of high quality
Responsibilities of the Quality Assurance Team To prepare a SQA plan Takes part in developing the process description of the projects software Evaluate the tasks of software engineering so that it abides by the defined software process Reviews the assigned software work products so that it abides by those defined by the software process
Asia Pacific Institute of Information Technology The changes in the software work and the work products are properly documented according to the procedure for it Keeps a track of any activity that is not compliant, and informs to higher authority.
Quality Management and Organization
Sponsor
Project Manager
Quality Manager
Integration Manager
Configuration Manager
QA Rep
Figure 9: Quality Organization
Quality Assurance Methods Internal Project Reviews These are project team work sessions in which the team reviews all deliverables for a phase before scheduling a methodology review. Walkthroughs These are group work sessions in which the walkthrough team validates the deliverable using previously defined scripts, presentations, question & answer sessions, and brainstorming sessions, if appropriate. Principles and Practices in Software Development 43
Asia Pacific Institute of Information Technology Inspections These are reviews of a deliverable by the Executive Committee, or sometimes by an implementation team, for the purpose of inspecting and approving the deliverable. (Anon, 2009) Defect Repair Control standard reporting mechanisms documentation that is up-to-date meetings at a regular basis reviews of existing documents
4.3 Risk Management Plan
4.4 Documentation Standards
Standards used in documenting are: a) IEEE standards b) Process standards c) Product standards d) Interchange standards
Document is a key element in a software project. Errors of software can lead to errors of end users and to system filatures. So managers, software engineers and professional technical writers are working for the documentation even before the development process begins. Document is help stakeholders to 1) communication medium between members of the development team 2) should be a system information repository to be used by maintenance engineers 3) should be a system information repository to be used by maintenance engineers 4) Some of the documents should tell users how to use and administer the system.
Documents depends the contract with client for the system, the type of system being developed and its expected lifetime, the culture and size of the company developing the system and the development schedule that is expected.
Types of docume nts:
1. Process documentation Plans These documents record the process of development and maintenance.
Schedules Principles and Practices in Software Development 46
Asia Pacific Institute of Information Technology process quality documents project standards Organizational
Process documentation. 2. Product documentation
This documentation describes the product that is being developed. Also essential for System documentation management of the system development
Describes the product from the point of view of the engineers developing and User documentation maintaining the system
Provides a product description that is oriented towards system users
Process Document Software is intangible and it apparently involves in similar cognitive tasks. Plans, estimates and schedules Reports
Produced by managers to help to plan and control software process
Standards
Report how resources were used during the process of development.
Set out how the process is to be implemented. These may be developed from Working papers organizational, national or international standards.
They record the ideas and thoughts of the engineers working on the project are, interim versions of product documentation, describe implementation strategies and set out problems which have been identified. They often, implicitly, record the rationale for Memos and electronic mail messages Principles and Practices in Software Development 47 design decisions
Asia Pacific Institute of Information Technology These record the details of everyday communications between managers and development engineers.
Product Documentation This the document of delivered product User documentation User document is about describing user to the way of software product use. System is always used by different kind of users. So this must help all of them to work with system. This is always about understanding the End user and System administrators.
End user Not in interested about the architecture and the designing side of the software. Just want to use the software
System administrators Co-ordinate user and software Engineer. Fix the software problems of user.
To document above caterings, User documentation need at least 5 chapters or five separate documents that must deliver with system. Functional requirement - Functional description Describe the service and function provided. Help user to decide whether system provided what they need. - System installation document This is for System administrators. Describe installation, hardware configuration etc. - Introductory manual Describe normal usage. Describe with examples even to understand by beginners. - System reference manual Principles and Practices in Software Development 48
Asia Pacific Institute of Information Technology Describe system facilities with full details. This should describe complete list of errors messages and recovering modes. This must me a complete. - System administrators guide Provide for system such as command and control systems to describe the massages generate by system.
System documentation This document describes system from the requirement analysis to final acceptance test plan. This Documents describing the design, implementation and testing is useful for maintaining.
This should include: 1. The requirements document and an associated rationale. 2. A document describing the system architecture. 3. Description of the architecture of the program for each program in the system. 4. Description of its functionality and interfaces for each component in the system. 5. Program source code listings. Should be commented, provide the logics used, use meaningful names and structured programming style. 6. Validation documents How each program is validated and how the validation information relates to the requirements. 7. A system maintenance guide Describes known problems with the system, describes which parts of the system are hardware and software dependents.
Asia Pacific Institute of Information Technology Document structure This has a major impact to users usability and readability since thats the meaning of documenting. a) Identification Title and identifiers b) Table of content Chapter names, sections, page numbers c) List of illustrations Titles, figure numbers d) About Document Describe different users to way of using document correctly e) Concepts Explain the conceptual background of software. f) Procedures Directions of complete the tasks that the system is designed to. g) About software commands Describe all commands that systems supports h) Error messages About the error messages system will generate and recovery methods. i) References j) Navigation methods Methods used in the document to help users to identify their current location and to move around the document. k) Index Key words and there reference pages. l) Searching Way of finding specific terms in a electronic document. ((IEEE, 2001))
Asia Pacific Institute of Information Technology Sample document cover page
4.5 Programming Standards

Software is always built by a team. When the program become larger and complex software mangers tend gather more programmers around it. Every programmer has his unique style and this always vary from one to another. When considering about software organization they tend to programming standard to minimize this uniqueness between programmers. Because having poor standard or not using standard can result - Code that cannot be understood or even read by others - Code that is difficult to debug and test - Code that is difficult to reuse - Duplication of effort, variables, and files names, etc. - Code that may result in technical hitches, system crashes, hangs, etc. - Code that may produce errors and bugs - Company and code depend on programmer Programming standard is a template for a particular organization. This is an effort make every programmer working in same format.
Flowing areas need to discuss when setting up Programming Standards document. Organization can refer the researches already done to build Programming Standards document. (e.g.:Hungarian notations, Pascal Casing, Camel casing, Standard follow by popular software companies) - Access to hardware units All of the access to hardware should be put to libraries. Libraries should be developed so that high level hardware actions are performed, and to get rid of confusing low level library calls. - Argument passing - Comments Principles and Practices in Software Development 52
Asia Pacific Institute of Information Technology Comments should always be used so that others who refer to the code will be able to understand it at a later time. Code should not be commented carelessly, it should be kept to date and explain the logic of what is happening in the code. - Data declarations References taken externally should be declared clearly, and the external data items names should clearly indicate the location they are in. Data types should not be mixed between function boundaries - Defining constants - Documentation - Error handling - Function declarations and returns - Function layout - Including files - Modular coding - Module layout - Messages: errors, warning, info and choices - Naming files - Naming variables - Object oriented management - Source code formatting - Standard techniques and algorithms - Style consistency - Terminology - User interface features and facilities - User interface look and feel - Using objects - Version control The version should be provided by the Configuration management system
Using a source code repository can take as a good practice in programming standard. Principles and Practices in Software Development 53
Chapter 5 PROJECT MANAGEMENT
5.1 Introduction to Software Project Management
Project management is a set of principles, practices, and techniques applied to lead project teams and control project schedule, cost, and performance risks to result in delighted customers. (Chapman J.R., 1997) Project management is a process of planning, monitoring, controlling and running a software project. Project manager is the personal who manage the software project and person who interface with initiators, suppliers and senior management.
Distinctive Characteristics
a. Intangible
Software is logical rather than a physical element. So can as unlike other physical products software project management involves high forms of intangibility. If we take an example manufacturing a physical product such as a computer involves hardware components, designs and manufacturing processes where you find high physical elements. Software management is logical rather than a physical system element. (Pressman 2001, p. 6)
b. Doesnt ware out
As pressman mentioned early in his book (pressman, p.6) software doesnt ware out. According to the changes in technology software keep updating. Designers tend to introduce new releases to update the software.
c. Not standardized
A Programmer has his own style. Various companies are maintaining various styles. Pressman mention this in his book (pressman 2001, p. 7).According to his words each software developer has his own way of developing software unlike producing a physical product there is no standard procedures; this can sometimes leads to errors when delivering them to customers. Each software developer has his own way of developing software unlike producing a physical product there is no standard procedures; this can sometimes leads to errors when delivering them to customers.
Project Management Activities

Proposal writing Project planning and scheduling Project costing Project monitoring and reviewing Personal selection and evaluation Complete the Project
Proposal writing A project proposal is a detailed description of a series of activities aimed at solving a certain problem. This communicate project plan to stake holders. The proposal should contain all requirements comes with project. Proposal writers goal is the recognized and accepts of his proposal immediately by stakeholders. This should contain: Justification of the project Activities and implementation timeline (Refer SCHEDULE PLANNING) Methodology (Refer SELECTION OF METHODOLOGY) Human, material and financial resources required (Refer COST ESTIMATION and REQUIREMENT ANALYSIS) Project planning and scheduling Project planning set out resources available to project, work beak down structure, a schedule for the work Refer Schedule planning for workload break down, work splitting, etc.
Asia Pacific Institute of Information Technology Project costing Explain all cost categories throughout the project. (Refer COST ESTIMATION)
Project monitoring and reviewing This are the techniques aimed at reducing the number of errors that pass into next phase of the development process. Project always compare current project process with the project plan and make changes to the plan when necessary. All measures are tracked are tracked against the estimates.
Personal selection and evaluation Get the proper people to do the project and allocating task to them individually. Project staffing Get the proper people to the project. Project needs a staff with different skill levels. This is very difficult because Manager Will able to identify no of people needed to complete or speedup a project correct people according to the task, duration, project budget, effort needed at the various time throughout the project and with experience in particular task that employer going do. Also manger needs to identify source of project which mean where that particular person from like internal from your department, internal from another department within your organization, hiring of a new employee, or hiring of contractors. In this section manger will be able to document Requirements for external candidates, including job classifications and descriptions Selection of candidates and assignments to tasks Availability and duration of assignment for all candidates In this section manger will be able to document
Giving proper training to the selected staff is also important. Manger should identify and ensure necessary skill levels for different profiles.
Asia Pacific Institute of Information Technology Project Planning
Project plan is the model that project team going to follow throughout the project process. This is can indentify as a type of type of contract between the stakeholders. It contain number of process including its scope, timing, cost, associated risks, estimating, forecasting, option analysis, decision- making, performance monitoring and control. Project managing process and maintain several project plans, update them throughout the project process when required. This is developed by project team members under the leadership of project manager who is the administrator of project. Working under a plan is always cost effective than just doing it according to team members favor. Working under good project plans give warning before a problem arise. We can identify some key elements in project planning. Products What products must the project deliver? What are the quality requirements associated with the products? Activities What activities are needed to deliver the products? Resources What resources are needed to carry out the activities? Schedule In what sequence should we carry out the activities? How long will the activities take to complete? Are the required resources available? How long will the project take overall? Budget What are the time-phased resource requirements and financial costs? How much will the project cost overall? Risks Are we talking unnecessary risks? Is the level of risk exposure commensurate with the risk appetite? Are there any opportunities that could be exploited? Assumptions What are the underlying assumptions associated with the plan (Project planning and control process guide, 2007)
Asia Pacific Institute of Information Technology Planning Process Flowing are the four key stages in developing a plan 1. Defining scope and responsibilities Developing work breakdown structure Identify activities & dependencies 2. Scheduling and time/resource analysis Estimating time & resources 3. Cost estimating Developing & scheduling Estimate cost 4. Risk analysis and response planning Create time phased budgets Analyze & priorities risks and budgeting Develop cost breakdown structure Specify organizational and Defining & analysis
Identify risks
Plan risk management action
Figure 9: Planning Process
Defining scope and responsibilities Defining & analysis Structure the product and define products, their purpose, and quality requirement and acceptance criteria. Developing work breakdown structure WBS and define work package, specify their products, quality requirements, acceptance criteria, assumption, risks, opportunities. Specify organizational and responsibilities Define the responsibilities of individual teams.
Scheduling and time/resources analysis Identify activities and dependencies Identify the activities to deliver each work, Identify milestone, important decision, external dependencies. Create activity network Estimate time and dependencies Estimate time and resources need to finish each activity. Develop and analyze schedule Identify critical path for activities.
Cost estimation and budgeting Develop cost breakdown structure Develop cost breakdown structure to estimating cost fo r each work package Estimate costs Create time phased budgets According to cost automation and resources develop budget
Risk analysis and response planning Identify risks Analyze and priorities risks Principles and Practices in Software Development 60
Asia Pacific Institute of Information Technology Plan risk management action
Several project types of project plans Quality plan: Shows the standards that will be implemented and quality procedures that will be used in the project. Validation plan: what kind of an approach taken and the resources used to validate the system. Configuration management plan: Describes the configuration management procedures and structures to be used. (Anon. 2008). Maintenance plan: describes the maintenance procedures that they will implement and the breakdown of costs for them. Staff plan: describes how theyre going to arrange the staff whether in groups or individually and how to develop their skills to complete the plan.
Asia Pacific Institute of Information Technology Work Breakdown Structure 1. Project Briefing 1.1 Introduction 1.2 Problem background 1.3 Proposed solution 2. Schedule Planning 2.1 Gantt chart 2.2 PERT chart 2.3 Workload matrix 2.4 Activity network 3. Selection of Methodology 3.1 Methodology description 3.2 Selection of methodology 3.3 Justification of the chosen methodology 4. Project Planning Control 4.1 Configuration Management 4.2 Software Quality Assurance Plan 4.3 Risk Management Plan 4.4 Documentation Standards 4.5 Programming Standards 4.6 Communication Mode 5. Project management 5.1 Project management description 5.2 Project planning process 5.3 Resource allocation 6. Cost Estimation 6.1 Cost estimation description 6.2 Application of cost estimation 7. Risk Management 7.1 Risk assessment Principles and Practices in Software Development 62
Asia Pacific Institute of Information Technology 7.2 Risk control 7.3 Risk identification 7.4 Risk analysis 7.5 Risk prioritization 8. Requirements Analysis 8.1 Requirements analysis description 8.2 Application of requirements analysis 9. Process Modeling 9.1 Context Diagram 9.2 Level 0 DFD 9.3 Level 1 DFD 9.4 Process Specification 10. Data Modeling 10.1 10.2 ER Diagram Entity life history
11. Data Dictionary 11.1 11.2 11.3 11.4 Data flows Data stores Processes Source and Sink
12. Design Principles and Concepts 12.1 12.2 Design principles and concepts description Application of design principles and concepts
13. Architectural Design 14. System Design 14.1 14.2 Interactive screen design Report design
15. Programming Environment 16. Testing 16.1 16.2 Test plan Quality matrices Principles and Practices in Software Development 63
Asia Pacific Institute of Information Technology 17. Documentation
Chapter 6 PROJECT RISK MANAGEMENT PLAN
6.1 Risk Management Concepts
Risk is a potential problem that might happen or might not happen. There are two types of risks that can occur. They are generic risks, the risks that are applicable for any software project and product-specific risks, the risks that can be only understood by the ones who have a clear knowledge about the technology, people and development environment of the project. Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty caused by the risks. Although the uncertainty of a risk occurring, risk management and analysis have to be performed for a successful project (Pressman R., 2003) As U.S Air Force, (1998 cited Pressman, 2003) states, there are four components of risks. Performance risk - the degree of uncertainty that the product will meet its requirements and be fit for its intended use Cost risk the degree of uncertainty that the project budget will be maintained Support risk - the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance Schedule risk the degree of uncertainty that the project schedule will be maintained and the product will be delivered on time. To manage the above mentioned types of risks, there are two main steps that are undertaken in risk management. They are, risk assessment and risk control. 1. Risk assessment Risk identification Principles and Practices in Software Development 64
Asia Pacific Institute of Information Technology 2. Risk control Risk analysis Risk prioritization
Risk- management planning Risk resolution Risk monitoring
These are the components for consideration under the above mentioned two main steps. The risk management process can be abstracted as below.
Figure 10 : Risk management process (Source: Tarigan A., n.d.) Each component in risk management process will be further discussed as below.
Risk assessment Risk assessment is to examine what risks might occur during system development and whether you have taken enough precautions to overcome the risk impact. Also what steps must be taken to prevent the risk from occurring. Risk identification
Asia Pacific Institute of Information Technology This is the effort made to identify the risks that might harm the project plan. With this identification, risk avoidance and risk control can be performed. This stage doesnt include any other details about risks it merely refers to the list of possible risks. Risk Analysis This is the step taken to estimate the probability of loss and the amount of loss that are caused by the risks and how it affects the software development. Also it discusses as to which phase of the development and which people of the project team will be affected by the risk. Risks will be rated according to the impact. Risk prioritization The risks that were identified and analyzed will then be prioritized. Prioritizing means to determine the level of the risk. It will be mapped to a risk matrix that identifies the prioritization level. This is done based on two criteria, probability of occurrence and the impact of the risk. These are then leveled as high, medium and low. A high risk needs to have strong correction measures in place immediately, as it can occur at any time. A medium risk needs to have correction methods, but there is no need to incorporate these immediately. A low level risk can have corrective methods, but it is also possible to accept the risk.
Risk Control Risk control is to evaluate whether a risk can be avoided or eliminated and what controls can be used to mitigate from the risk. This also is the process of correcting risk deviations from the planned risk mitigation actions. Risk management planning Each risk will be addressed individually alone with the techniques and strategies to mitigate the risk. High level risks will definitely need to have a mitigation plan. Risk resolution
Asia Pacific Institute of Information Technology The stage in which, the plans for mitigating the risks are applied. These strategies will be definitely implemented for the high level risks and if needed for medium level risks.
Risk monitoring This is to constantly monitor the effectiveness of the strategies implemented to mitigate the risk. If the strategy fails to mitigate the risks, risk analysis must be performed again as illustrated in Figure 9(process of risk management.)
Risk Owner is the person or the group who is given the responsibility of a risk. They must identify that a risk has occurred and then implement the mitigation plan and continuously monitor the mitigation strategy. Each risk has to be assigned a risk owner for a project
Roles and responsibilities of stakeholders in risk manage ment Table 1: Roles and responsibilities of stakeholders in risk management
Role Program manager Project manager Risk Management Responsibility Supports and funds for risk management Manages risks associated with development and
maintenance of the system. Ensures that risk management is performed in consonance with the process described Risk Management Manager Ensures that risk management is performed as described in the risk management plan Software Risk Evaluation (SRE) Team SRE Facilitator Software Quality Analyze and document risks associated with the tasks project performs Performs quality engineering activities of the project Assurance Reviews the risk management activities to ensure that the risk management plan is followed Management Performs risk tracking
(SQA) Manager Configuration

Manager Reports status of designated risks to the Risk Manager Maintains Risk Management details Provides summary information to the Risk Manager to be used in developing project risk-related reports
(Department of Energy Quality Managers Software Quality Assurance Subcommittee, 1999) Risk Mitigation These are the steps taken to control risk and to minimize its impact on the system. There are four options to mitigate from risk. Risk Assumption This is to accept the potential risk. This is used when the project team cannot do anything about the risk. Risk is assumed to be simply accepted if it occurs. Risk Avoidance Choosing an alternative approach to minimize the effect of the risk, it cannot be completely eliminated. Certain changes can be made to the project tasks in order to avoid the risk. Risk Limitation This is done by constantly monitoring and correcting risk s that can occur. This is done by using reviews and inspections and management techniques. A risk reduction plan is drawn for this purpose Risk Transfer The risk is said to be outsourced or transferred to another organization or upward within the organization.
6.2 Risk Management Plan

Risks were categorized and identified as performance, support, cost and schedule risks.
Risk Performance Tasks and responsibilities might not be evenly distributed Prepare interviews and questionnaire to meet our information requirement is not successful Information might be misleading
Effect
Mitigation
Chance to occur Low
Impact of Risk High
Risk Owner
Might not get the required permission from the organization to obtain information Might not be able to target and focus on user requirements
Make sure to carry out Medium the investigation phase carefully and obtain correct information from the users Cannot be able to Discuss with the Medium come up with the members and the users best solution for the and get their reviews problem to bring out the best solution Meet unexpected Might result in to Risk management is High situations or risks facing unexpected done to identify risks situations, that might priorPrinciples and up and come Practices in Software
Tasks might not be completed in its best state or incompletion of tasks The new system might be incomplete since we are not aware of the system requirements because they were never investigated The system might be built up on wrong information, which means that the system has no real effect and is not useful System might not meet user requirements, since we are not aware of its needs and faults The new system might not be effective and might not meet user requirements The new system might not be as expected
List down all the tasks and distribute evenly among members considering its capacity Make sure we investigate and obtain all the necessary information about the system and that nothing is left out Make sure to verify the information we get before putting in them to use therefore avoid build of improper system First get permission from APIIT to visit the organization and then make the visit
Medium
High
Medium
High
Low
Medium
High
Low
High
Development 69

slow down and decrease the quality of the whole project Lack of Testing might be requirements incomplete and inaccurate People we meet for The whole project fact finding might might be mislead provide wrong and not reach user information requirements with methods overcome them to
Consider sufficient amount of test cases Make sure we meet the right people who are aware of the system and has an understanding of how system works the team informed they are
Low
High
Medium
High
Support Team might leave
members Project tasks cannot Keep be carried out members and how
Low
High
about the tasks done
being done Project experience knowledge Making decisions team Will fail problems Research about them make Medium High
members with lack while
conducting and
and project tasks, as to clarifications with the how they are done wrong Result in lecturer with team Low High
wrong Discuss
functionalities of the members, argue and system and bad come up with the best decisions design, schedule is not met
Might not be able to Cannot provide discover all the solutions for the faults of the current current system faults system Forms might have to Might cause clashes be changed during and mismatches designing with the database and logic Forms might not be The users might find user friendly it hard to make use of the system
Analyze the current system carefully and verify from the users, the faults they want to be fixed Plan the forms to match the features and contents of the database Always verify and get ideas of the users while designing the
Low
High
Medium
Medium
Low
Medium

system The user might not Understand the find the system requirements and useful when confirm that the fulfilling the requirement is met requirements The system might All members must be have a lot of bugs aware of what others and it might be are doing and do their unstable part to match others work Might not be Verify whether the implemented and features can be added improper coding my and which best way to lead to system errors implement them Might cause Use a common conflicts among programming members and the language and common parts of coding they software which is have completed familiar, known and individually. All convenient with all parts of code may members of the group not be able to be combined to one Might miss out Discuss with the certain functions of members and make the system and sure nothing is missed therefore out. And if possible clarify the DFD with the target users Knowledge of all Keep track of the DFD processes and their when designing the functions are low data dictionary Be careful to cover up all the objectives and functions of system before designing the hierarchy chart. Plan the design properly from the beginning itself and
User requirements (needed output) could not be obtained Distributed parts of coding (among members) can cause problems when combined New features included in the system may not function properly Software and the programming language that is used might not be familiar with all members
Low
High
Low
High
Medium
High
Low
High
All the contents of the system might not be included in the DFD
Low
Medium
Data dictionary might not explain everything in the DFD System might not be able to be designed to fulfill the features stated in the hierarchy chart
Low
Medium
The organization of the project is low and will have to meet up with unexpected challenges Database design Might create might not map with problems while the user interface coding, and conflicts
Low
Medium
Low
High

may occur If the logic was changed, the database entities would have to be changed Not assigning proper people to work Might cause huge problems in the system design and the coding The new system that is to be built might have been mislead and not very accurate create the database accordingly Plan the design properly from the beginning itself and make sure no problems would arise Select the system and people carefully, which are relevant to our project and make sure the people are really aware of the system matters Get online help and other resources to identify bugs and then fix them Organize the project and plan from the beginning in order to complete the project on time , while reaching all targets Complete the design on time and focus a considerable amount of time for testing
Low
High
Low
High
All bugs are not The system might identified not be built completely and accurately Insufficient team Improper system and lack of resources design, that is not error-free and cannot complete on time Testing incomplete System might not run as smoothly as expected and might consume of several bugs
Medium
High
Low
Low
Low
High
Cost and Schedule Preparing a Gantt chart that is practical and effective, specially time allocation
Might not be able to complete the project on time and some tasks might be missed out, which might lead to an overall delay Hard disk fails, Cannot finish the processor fails, development on external storage time. drivers fails Team members Cannot finish the might not work development on
Discuss with all the members and decide the time required to each task and make sure that no task is left out Keep sufficient back up with all team members. Keep discussions and review work of the
Low
Medium
Low
High
Medium
High

according to the time schedule time group members to keep them encouraged
Chapter 7 COST ESTIMATION
7.1 Techniques for Cost Estimation
Cost components Cost component in a project can be categorized into two sections. 1. Direct cost (touch labor) This include cost which have direct bearing on the production Manufacturing, engineering, quality assurance, material etc and direct none wage costs such as training, suppliers and travel. 2. Indirect cost (over headed) This includes such things as general & administrative support, rent, utilities, insurance, network charges, and fringe benefits. Example: Sick/annual leave, retirement, health insurance
Cost estimating techniques There are mainly five techniques available for estimating costs 1. Expert judgment 2. Estimate by analogy Principles and Practices in Software Development 73
Asia Pacific Institute of Information Technology 3. Algorithmic cost estimation 4. Parkinsons Law 5. Pricing to win Expert judgment
In this methodology several experts on the proposed software development technique and application domain are involved. They each estimate using their own estimate methods and experience. This technique can use for in assessing differences between past projects and new ones for which no historical precedent exists. Because of the limited historical dated needed this technique is very useful for when new or unique projects. Delphi or PERT techniques use as expert-consensus in the judging Delphi technique Before the estimation, a group meeting involving the coordinator and experts is arranged to discuss the estimation issues 1. The coordinator presents each expert with a specification and a form to record estimates 2. Each expert fills in the form individually (without discussing with others) and is allowed to ask the coordinator questions. 3. The coordinator prepares a summary of all estimates from the experts (including mean or median) on a form requesting another iteration of the experts estimates 4. Repeat steps 2)-3) as many rounds as appropriate
After each round of estimation, the coordinator calls a meeting to have experts discussing those points where their estimates varied widely. Steps repeat until a stable estimate result.
Asia Pacific Institute of Information Technology Estimate by analogy This estimation technique require past completed projects that are similar to the new one. This can be done either at the total project level or at subsystem level. The strength of this method is that the estimate is based on actual project experience. Here also sometimes technical experts consult for complexity factors, technical, performance or physical differences.
This technology mostly use when New system mostly similar to old system When the new systems technology, programmatic assumptions are advance to use other existing estimating techniques. This can use as a second technique to estimate
This is always based on actual experience of the analogous system, inexpensive to use, there is a unrealistic and must have a detailed technical knowledge of program and analogous system. Also its hard to find a system thats very much similar to the new system.
The process of estimating I. II. III. IV. V. VI. VII. Determine estimate needs/ground rules Define new system Breakout new system into subcomponents for analogy estimating, Assess data availability of historical similar systems, Collect historical system component technical and cost data, Process/normalize data into constant year dollars (e.g., constant FY2003$), Develop factors based on prior system Example: Program Management is 10% of total development cost
VIII.
Develop new system component costs Obtain complexity (and other translation) factors Apply factors to historical costs to obtain new system costs Apply factors to historical costs to obtain new system costs Principles and Practices in Software Development 75
Algorithmic cost estimation
This mainly based on a mathematical function. A model function is developed using historical cost information that modeling relates some software metric (usually its size) to the project cost. Effort=f (X1, X2X3, Xn) Parkinsons Law (work expands to fill the time available) This technique determine by available resources. If the software has to be delivered in 12 months and 5 people are available, the effort is estimated to be 60 person- months. This sometimes gives good estimation but since this is do not go for a estimation its hard to recommend this as a good technique.
Pricing to win Estimation model depend on the customers budget and dont care the systems functionality.
7.2 Cost Estimation
Factor Table 2: Cost Estimating Factors a. Backup and recovery

b. Data communication c. Distributed processing d. Performance critical e. Existing operating environment f.
4 2 0 4 3 4 5 3 5 5 4 3 5 3 46
On-line data entry
g. Input transaction over multiple screens h. ILFs updated online i. j.
Information domain values Internal processing Complex
k. Code design for reuses l.
Conversion/installation in design
m. Multiple installations n. Application design for change
Values adjustment factor
Asia Pacific Institute of Information Technology Function point Calculation Table 3: Function point calculation
Short Measurement Parameter form of Count Complexity (Simple/ Average/ Complex)
10 8 10 5 4 4 5 4 10 7 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 40 40 40 50 28 198
Simple
Average Complex Total
parameter
No. of external user inputs No. of external user outputs No. of external user inquiries No. of internal logical files No. of external interface files Count Total
EI EO EQ ILF EIF
FP=count total*[0.65+(0.16*46)]=56
Chapter 8 REQUIREMENT ANALYSIS
Chapter 9 PROCESS MODELLING

9.1 Context Diagram
DFD 0
Membership details Requests Request parent details Rejected request
9.2 Level 0 DFD

Customer
Receipt Fine details Rejected request Rejected request Renewal details Receipt Request acceptance note Return acceptance details
Borrow details
Rejected lending request
Figure 11: Context Diagram

Request child account approval Approved request
Payment details
Payment details Parent details Request membership Return details Request renewal
0 Entertainment Items Rental System
Feedback Customer details Borrow request Purchase request
Parental details
Item details Accounts reports Inventory reports Feedback reports

Disapproved request Parent
Sales reports Lends reports Requests reports Members reports
Owner
Item details
Owner
5.0 Add Items
Item details
Borrowable items details Borrowed Item details

Accounts report Members report
Lend details Borrow details

Rejected lending request Borrowing request
Inventory report
Lending details
3.0 Return Items Fine details Receipt Return acceptance details Fine details
Request renewal
D1 Inventory
Inventory details
Renewability details 4.0 Extend Loan

Return details Payment details
Returned items details Purchased Item details Purchasable items details Lends details
Renewal details Rejected request Customer
D4 Accounts Payment details Receipt Purchase request 2.0 Purchase Items Purchase details Purchase details Rejected request
Accounts details
9.0 Report Handling
Sales details
Requests details
Feedback report
D2 Lends
D3 Sales
Parent details Request parent details
Request new items Request acceptance note Feedback
Customer details 8.0 Process Feedback
Rejected request 7.0 Register Customer
Structured feedback
D6 Feedbacks
Membership details
Membership details Non-member parent registration details Children details Approved request Request child account approval Parental details Disapproved request Parent
D7 Members
Member details
Figure 12: DFD 0
Request Children details
6.0 Request New Items
Item details
D5 Requests
Feedback details Children account details
Request membership
Sales report
1.0 Borrow Items
Requests report
Lends report
9.3 Level 1DFDs

DFD 1.0
Customer
Borrow request
1.2 Receive borrow request Rejected lending request
Lending details
1,1 Verify request
Availability Request
D2 Lends
Accepted request
1.3 Check availability
Borrow details
1.4 Lend item D1 Inventory
Borrowable items details Borrowed Item details
Figure 13 : DFD 1.0
Asia Pacific Institute of Information Technology DFD 2.0
Purchase request
2.1 Receive request
Customer
Rejected request
Request Receipt 2.2 Verify request
Payment details
2.3 Sell item
Accepted request
2.4 Check availability
Purchased Item details Purchase details Purchase details Purchasable items details
D1 Inventory D4 Accounts
D3 Sales
Figure 14: DFD 2.0
Return acceptance details
Customer
Return details
Fine details 3.1 Receive return details
Return details Receipt
3.4 Charge fine Payment details
Accept return
3.3 Accept return
Returned items details 3.2 Check return details Borrow details
Fine details
D2 Lends
Fine amount
3.5 Calculate fine
Fine available loans
D1 Inventory
D4 Accounts
Figure 15: DFD 3.0
Customer
Request renewal
Renewal details
4.3 Renew item Rejected request
4.2 Receive renewal request D2 lends Item details
Accepted request 4.1 Check renewability 4.4 Verify request Renewability Renewability details
Figure 16: DFD 4.0
Owner
Item details
5.1 Update inventory
Item details
5.2 Receive item details
Item details
D1 Inventory
Figure 17: DFD 5.0
Customer
Request new items
D5 Requests
Request acceptance note 6.1 Receive new item request Request 6.2 Process request Item details
Figure 18: DFD 6.0
Request membership Customer Rejected request
Customer details 7.1 Receive customer details Request parent details Customer details Membership details
Parent details
7.3 Handle underage customer details
Underage customer details Parental details
7.2 Check customer details
7.4 Request child account approval 7.5 Generate membership details
Approved membership
Membership details
Request child account approval
Approved request Parent
Disapproved request
7.6 Reject membership
D7 Members
Parental details
Non-member parent registration details
7.7 Create parent membership
Non-member parental details
Children details
7.8 Update parental details
Member parental details
7.9 Check parent membership
Figure 19: DFD 7.0 Principles and Practices in Software Development 98
Customer
Feedback 8.1 Receive feedback
Structured feedback Feedback 8.2 Process feedback
D6 Feedbacks
Figure 20: DFD 8.0
9.4 Process Specification
Number Name Description
3.2 Check return details When an item is returned, checks the borrow details, checks for fines and accepts the returned item.
Input Data Flow Output Data Flow
Return details from process 3.1, Receive return details Accept return to process 3.3, accept return Borrow details to data store D2, lends Fine details to process 3.5, calculate fine
Type of Process Process Logic
Online If not due date expired Accept item Update borrow details else Calculate and collect fine
3.5 Calculate fine When an items due date is expired, calculate and charge the fine amount from the borrower Fine available loans from process 3.2, Check return details Fine amount to process 3.4, Charge fine Online Fine _amount = (Return _date Due_date)*Fine_rate_per_day
Input Data Flow Output Data Flow Type of Process Process Logic
4.1 Check renewability when a borrower requests to extend borrow loan, checks whether the loan can be renewed
Input Data Flow
Item details from process 4.2,receiver request

Renewability details from data store D2, lends Output Data Flow Type of Process Process Logic Renewability to process 4.4, verify request Online If (renewability ==true) Extend loan Else Reject renewal request
Number Name Description Input Data Flow Output Data Flow Type of Process Process Logic
4.3 Renew item When an item loan can be renewed when requested, extends the loan Accepted request from process 4.4, Verify request Renewal details to Customer Online If (renewability ==true) Extend loan Send renewal details to customer Else Reject renewal request
Number Name Description Input Data Flow Output Data Flow Type of Process Process Logic
4.3 Renew item When an item loan can be renewed when requested, extends the loan Accepted request from process 4.4, Verify request Renewal details to Customer Online If (renewability ==true) Extend loan Send renewal details to customer Else Reject renewal request

Number Name Description 7.2 Check customer details Takes in customer details, checks for underage accounts which needs approval and accept other requests Input Data Flow Output Data Flow Customer details from process 7.1, Receive customer details Underage customer details to process 7.3, Handle underage customer details Approved membership to process 7.5, Generate membership details Type of Process Process Logic Online If (customer_age<18) Mark as underage Send underage customer details to verify Else Approve membership to generate membership details
Number Name Description Input Data Flow Output Data Flow
7.9 Check parent membership Checks whether the parent is already a member of the company and update details Parental details from Parent Member parental details to process 7.8, Update parental details Non-member parental details to process 7.7, Create parent membership
Type of Process Process Logic
Online If (parent is a member) Update parents membership records Else Create a non-member parent record for parent
Chapter 10 DATA MODELLING

10.1 Entity Relationship Diagram

Category
Available in
Category_ID Category_Name
Available in
Available in
Actor Actor_ID Name

Acts in
Movie Movie_ID Name Catogory_ID Format Director_ID Starring_ID Language Run_Time Release_Year Wallpaper Trailor Studio Description Games Game_ID Name Category_ID Publish Release_Year Trailor Language No_of_Players Developer Wallpaper Trailor
Song Song_ID Name Format Artist_ID Release_Year Language Category_ID Wallpaper Composer_ID
Composes
Composer Composer_ID Name
Artist
Sings in
Director Director_ID Name

Directs
Artist_ID Name
Is available in Is available in Is available in
Album Album_ID Artist_ID No_of_Songs Publisher Feedback Feedback_ID Item_ID Member_ID Comment Rate Date
Inventory Inventory_ID Item_ID Purchase_Copies Rent_Copies Purchase_Copies_In-hand Rent_Copies_In-hand Available
Gives about
Borrow
Gets from
Borrow_ID Item_ID Member_ID Borrow_Date Fine Renew Return_Date

Can have
Sales Sales_ID Item_ID Member_ID Receipt_ID Purchase_Date
Provides
Member
receives
Receives
Fine Fine_ID Borrow_ID Overdue Amount

pays
Member_ID Name Address Telephone_No Email Parent_ID Status Activate Date_of_Birth Borrowable_Amount Account NIC_No Child User_Name Password
Requests Request_ID Item_Name Item_Type Description Date_of_request Receipt

Receives
Makes
Receipt_ID No_of_Items Total Pay_Mode
10.2 Entity Life History
Members
Members
Customer Registers
Member life
Membership archive
Change Member details
Inventory
Inventory
Add New item
Inventory life
Item archive
Edit items
Rent items
Sells items
Add items
Change item details
Lends item
Returns item
Feedbacks
Feedbacks
Member provides feedback
Feedback life
Feedback archive
Provide feedback
Requests
Requests
Member makes request
Requests life
Requests fulfilled
Make requests
Borrows Principles and Practices in Software Development 106
Borrows
Request item
Borrow life
Return item
Borrow item
Change borrow details
Pay fines
Extend Loan
Purchase
Purchase
Request Item
Purchase life
Purchase archive
Purchase item
Chapter 11 DATA DICTIONARY

11.1 External Entities
Name Description
Input Data Flows
Output Data Flows
Customer The customer borrows and purchases items from the company, makes requests for new items and provides feedback about the system and items Rejected lending request from process 1.0, Borrow Items Lending details from process 1.0, Borrow Items Fine details from process 3.0, Return Items Receipt from process 3.0, Return Items Return acceptance details from process 3.0, Return Items Renewal details from process 4.0, Extend Loan Rejected request from process 4.0, Extend Loan Receipt from process 2.0, Purchase Items Rejected request from process 2.0, Purchase Items Request acceptance note from process 7.0, Request New Items Rejected request from process 6.0,Register Customer Request parent details from process 6.0,Register Customer Membership details from process 6.0,Register Customer Parent details to process 6.0,Register Customer Request membership to process 6.0,Register Customer Customer details to process 6.0,Register Customer Feedback to process 8.0, Process feedback Request new items to process 7.0, Request New Items Purchase request to process 2.0, Purchase Items Payment details to process 2.0, Purchase Items Payment details to process 3.0, Return Items Return details to process 3.0, Return Items Request renewal to process 4.0, Extend Loan Borrowing request to process 1.0, Borrow Items
Name Description
Parent Approves children membership and gets feedback about the children Principles and Practices in Software Development 108
Asia Pacific Institute of Information Technology borrow and purchase details Request child account approval from process 6.0,Register Customer Children account details from process 9.0, Handling reports Disapproved request to process 6.0,Register Customer Approved request to process 6.0,Register Customer Parental details to process 6.0,Register Customer Request Children details to process 9.0, Handling reports
Input Data Flows Output Data Flows
Name Description Input Data Flows
Output Data Flows
Owner Adds new items for rent and purchase and gets reports about the system. Accounts reports from process 9.0, Report Handling Inventory reports from process 9.0, Report Handling Feedback reports from process 9.0, Report Handling Sales reports from process 9.0, Report Handling Members reports from process 9.0, Report Handling Lends reports from process 9.0, Report Handling Requests reports from process 9.0, Report Handling Item details to process 5.0, Add Items
11.2 Process
Name Description Input Data Flows Output Data Flows
Process
1.0 Borrow Items Receives borrow details from customer and lets them borrow items and stores records about the borrows Borrowing request from customer Borrowable items details from data store D1, Inventory Rejected lending request to customer Lending details to customer Lend details to data store D2, Lends Item details to data store D1, Inventory BEGIN Get borrow item details Check item availability IF available Rent item Principles and Practices in Software Development 109
Asia Pacific Institute of Information Technology Update borrows and inventory files ELSE Reject request ENDIF END
Output Data Flows
Process
2.0 Purchase Items Allows customer to purchase an item he requests and keeps records about the purchase. Purchase request from Customer Payment details from Customer Purchasable item details from data store D1, Inventory Rejected request to customer Receipt to Customer Item details to data store D1, Inventory BEGIN Get purchase item details Check item availability IF available Sell item Update purchase and inventory files Receive payment from Customer Produce receipt to Customer ELSE Reject request ENDIF END
Name Description Input Data Flows Output Data Flows
3.0 Return Items Accepts items that are returned by the customer and checks for overdue loans and charge fine Return details from Customer Payment details from Customer Return acceptance details to Customer Receipt to Customer Fine details to Customer Principles and Practices in Software Development 110
Asia Pacific Institute of Information Technology Borrow details to data store D2, Lends Payment details to data store D4, Accounts Purchased item details to data store D1, inventory BEGIN Get borrow item details Check due date IF due date expired Calculate fine Charge fine Update accounts file Produce receipt to Customer ENDIF Accept returned item Update lends and inventory files END
Process
Name Description Input Data Flows Output Data Flows Process
4.0 Extend Loan Renewals a loan by extending the due date when a customer requests Request renewal from customer Renewability details from data store D2, Lends Renewal details to Customer Rejected request to Customer BEGIN Get item details Check due date Check renewability IF item can be renewed Extend loan Update lends file ELSE Reject renewal request ENDIF END
5.0 Add Items Allows the owner to add new items to the system(company) Item details from Owner Principles and Practices in Software Development 111
Asia Pacific Institute of Information Technology Output Data Flows Process Item details to data store D1, Inventory BEGIN Get item details Update inventory END
Output Data Flows
Process
6.0 Register Customer Gets customer details and registers a customer as a member of the system Customer details from Customer Request membership from Customer Parent details from Customer Approved request from Parent Disapproved request from Parent Parent details from Parent Rejected request to Customer Membership details to Customer Membership details to data store D7, Members Non-membership parent registration details Children details to data store D7, Members Request child account approval to Parent BEGIN Get customer details Check details IF age <18 Request parent details Request parent approval IF parent approves Create membership Update members file Give membership details to customer ELSE Reject membership ENDIF ELSE Create membership Update members file Give membership details to customer ENDIF Principles and Practices in Software Development 112
Asia Pacific Institute of Information Technology END
Name Description Input Data Flows Output Data Flows Process
8.0 Process Feedback Accepts feedback about items and system and provide child account feedback to the parents Feedback from Customer Member details from D7, Members Structured feedback to data store D6, Feedbacks BEGIN Get customer feedback Structure feedback Update feedbacks file END
Output Data Flows
Process
9.0 Report Handling Gets details from the database and provides the owner with reports Member details from data store D7, Members Feedback details from data store D6, Feedbacks Requests details from data store D5, Requests Sales details from data store D3, Sales Account details from data store D4, Accounts Lends details from data store D2, Lends Inventory details from data store D1, Inventory Request Children details to process 9.0, Handling reports Member report to Customer Feedback report to Customer Requests report to Customer Sales report to Customer Accounts report to Customer Inventory report to Customer Children account details from process 9.0, Handling reports BEGIN Get member details, feedback details, requests details, sales details, accounts details, lend details, inventory details Provide member report, feedback report, requests report, sales report, accounts report, inventory report to owner and c hildren account Principles and Practices in Software Development 113
Asia Pacific Institute of Information Technology details to parents END
11.3 Data Stores
Name Description Input data flows
Output data flow
Data structure
D1 Inventory Stores details of items Item details from process 5.0, Add Items Borrowed item details from process 1.0, Borrow Items Returned item details from process 3.0, Return Items Purchased Item details from process 2.0, Purchase Items Inventory details to process 9.0, Report Handling Borrowable items details to process 1.0, Borrow Items Purchasable items details to process 3.0, Purchase Items = Inventory ID+ Item ID + no. of copies for purchase + no. of copies for rent + no of copies in hand for purchase + no of copies in hand for rent *items details are stored in separate files for movies, games and songs which will be referred to from inventory file*
Name Description Input data flows Output data flow Data structure
D2 Lends Stores details about the borrows made Lend details from process 1.0, Borrow Items Borrow details from process 3.0, Return Items Renewability details to process 4.0, Extend Loan Lend details to process 9.0, Report Handling = Borrow ID + Item ID + Member ID + borrow date + fine parity+ renew parity + return date
Name Description
D3 Sales Stores details about the purchases made Principles and Practices in Software Development 114
Asia Pacific Institute of Information Technology Input data flows Output data flow Data structure Purchase details from process 2.0, Purchase items Sales details to process 9.0 Report Handling = Sales ID + Item ID + Member ID + Receipt ID + Purchase ID + purchase date
D4 Accounts Stores payment details Fine details from process 3.0 Return Item Purchase details from process 2.0, Purchase Items Accounts details to process 9.0 Report Handling = Receipt ID + amount + date of payment
D5 Requests Stores details about the requests made by the members Item details from process 7.0, Request New Details Request details from process 9.0 Report Handling =Request ID + item name + item type + description + date of request
D6 Feedbacks Stores customer feedbacks details about items and system Structured Feedback from process 8.0, Process feedback Feedback details from process 9.0 Report Handling = Feedback ID+ Item ID + Member ID + comment + rate
Name Description Input data flows
D7 Members Stores customer payment details Children details from process 6.0, Register Customer Non-member parent registration details from process 6.0, Register Customer Membership details from process 6.0, Register Customer Principles and Practices in Software Development 115
Asia Pacific Institute of Information Technology Output data flow Data structure Members details from process 9.0 Report Handling = Member ID + name + address + telephone no. + email + NIC no+ Parent ID + account status + activate + date of birth + borrowable amount + account + user name +password
11.4 Data flows
Name Description Origin/Source Destination/Sink Data structure
Lends report Gives the owner details about the borrows made 9.0 Report Handling Owner = Lend ID + Item ID + Member ID + borrow date + return date + (fine amount)
Sales report Gives the owner details about the purchases made 9.0 Report Handling Owner = Purchase ID + Item ID + Receipt ID + (Member ID) + pay mode + Amount + purchase date
Requests report Gives the owner details about the requests for new items made by the customers 9.0 Report Handling Owner = Request ID + name + type of item + Member details + description
Name Description
Feedback report Gives the owner details about the feedback about items and system made by the customers Principles and Practices in Software Development 116
Asia Pacific Institute of Information Technology Origin/Source Destination/Sink Data structure 9.0 Report Handling Owner = Feedback ID + Item ID + item name + item type + Member ID + rating + comment
Accounts report Gives the owner details about the payments made 9.0 Report Handling Owner = Receipt ID + Purchase ID + Item ID + Price + date of sale
Inventory report Provides the owner details about the inventory 9.0 Report Handling Owner = Item ID + Name + item type + sold amount + rented amount + copies in hand for rent + copies in hand for sale + price
Member reports Provides the owner details about the members 9.0 Report Handling Owner = Member ID + name + address + telephone no + email + items borrowed + fine history + account + account status + child accounts
Borrowing request Request made to borrow an item Customer 1.2 Receive borrow request = Item ID + Membership ID Principles and Practices in Software Development 117
Lending details Gives the lend details to the customer 1.4 Lend item Customer = Item ID + Due date
Request renewal Customer request to extend loan Customer 4.2 Receive renewal request = Item ID + Member ID
Renewal details Gives the renewal details to the customer 4.3 Renew item Customer =Item ID + extended due date
Fine details Provides the customer with fine details 3.4 Charge fine Customer =Item ID + overdue dates + fine amount
Name Description
Payment details Provides payment details to the system Principles and Practices in Software Development 118
Asia Pacific Institute of Information Technology Origin/Source Destination/Sink Data structure Customer 3.4 Charge fine = Amount + Pay mode
Customer details Provides the customer details to the system Customer 7.1 Receive customer details =First Name + Last Name + Age + Date Of Birth + Email + NIC Number + Address + Telephone no. + {preferences}
Parent details Provides the parental details to the system Customer 7.3 Handle underage customer details = Name + Email + NIC Number + Address + Telephone no. + (parents membership ID )
Membership details Provides membership details to the customer 7.5 Generate membership details Customer = Membership ID + Account status
Name Description Origin/Source Destination/Sink
Feedback Provides feedbacks about system and items made by the customer Customer 8.1 Receive Feedback Principles and Practices in Software Development 119
Asia Pacific Institute of Information Technology Data structure =Item ID + rating + comment
Request new item Customer makes requests for new items from the system Customer 6.1 Receive new item request =Item Name + Item type+ description
Item Details Owner provides the system with details of the new items available Customer 5.2 Receive item details =Item name + item type + {artists | actors | director|} + no of copies for rent + no of copies for sale + {item category}
Chapter 12 DESIGN PRINCIPLES AND CONCEP TS
12.1 Design Principles and Concepts
This is an engineering representation of tracing customers requirements in predefined criteria to certify quality of product. Software design is the only phase that customers requirements are fully transferred into a finished software product. Furthermore, this is the only phase in which the customers requirements can be accurately translated into a finished software product or system. This is like no one builds a house without a design without an approved blueprint. It is always a risk. This describes the detail of data structure, system architecture, interface, and components. At the end of the design process a design specification document is produced. This document is composed of the design models that describe the data, architecture, interfaces and components. Product without proper design is always a risk and it will fail even with small changes, difficult to do testing, sometimes its hard to assure the quality of product until the last stage of development process. This Software Design focused on major areas: Data design Transform the information domain model created during the analysis (ERD and data dictionary) into the data structures. Architecture design Define the relationship among major structural elements of the program. Modular framework of a computer program can be derived from the analysis model and interaction of subsystems depicted in DFD Principles and Practices in Software Development 121
Interfaces design Describes how the software communicates within itself, with human who use it, to system. Data flow and control flow diagrams provide the information required.
Procedurals design Transfer structural elements of the program architectural into a procedural description of software component information. Components using information obtained from the process specification (PSPEC), control specification (CSPEC), and state transition diagram (STD) (Pressman, 2003)
Design Principles
According to pressman design model is equivalent to the architects plans for a house. It begins by representing the totality of the entity to be built (e.g. a 3D rendering of the house), and slowly refines the entity to provide guidance for constructing each detail (e.g. the plumbing layout). Similarly the design model that is created for software provides a variety of views of the computer software. This is a process of steps that allow user to clearly describe all the aspects, characteristic of software to be built. Anyway for a successful design designer must have the creativity skill, experience gained, an understanding on how to develop a good looking software, and full commitment to the quality are required.
Tunnel vision should not be experienced by the design A good designer always has alternative design approaches. This depends on the requirements of the problem, the resources available to do the job, design concepts and other constraints.
The design should be able to be traced back to the analysis model It is necessary to have a method for keeping track of the requirements. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means of track. So that it can be determined whether it has been satisfied by the design model.
The design of the system should not be reinvented Systems are built with many design patterns, with some being very similar to the ones used before. Designer should try to reuse these patterns with modifications. Because time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist
Asia Pacific Institute of Information Technology The design should be able to increase the closeness between the software and actual problem in real world The problem area should be very similar to the structure of the software design and should (whenever possible) mimic the structure of the problem domain.
The design should be consistent and combined The designs should all look like only 1 person made them, and it is easy if the rules of styles and format are defined for design team before design work begins. If interfaces between design components are defined clearly, then integration will be of no problem.
The design should be able to be changed later if required To be able to facilitate change, the design concepts must be followed.
When unexpected events or operations occur, the design should be able to close or display the error in a graceful manner. Software that is designed properly should be able to handle error situations in a calm manner; it should never look like the program is crashing.
The design should remain as it is, and coding as it is. Even though detailed procedural designs are made for the modules of a program, the level of abstraction is greater than the code. The only design decisions made of the coding level address the small implementation details that enable the procedural design to be coded.
As the design is being built, it should be evaluated for its quality, not after it is completed. In order to measure the quality of the design a list of design concepts and measures need to be adhered to.
The design needs to be reviewed once again, to reduce potential of errors. Principles and Practices in Software Development 124
Asia Pacific Institute of Information Technology Before addressing the syntax errors, the design should be checked and reviewed for conceptual elements, by making sure that these do exist in the design.(Pressman, 2003)
A design which following this design principles always with external quality factors (speed, reliability, correctness, usability) and internal quality factors. External quality factors are always for users and internal duality factors is important to software engineers.
Software Design Concepts

Software design concepts help designer to answer following questions which occur in designing process. How to partition software into individual elements? Identify the difference between data structural details and conceptual representation of software. Identify uniform criteria of a software design.
The fundamental design concepts are: a. Abstraction - data, procedure, control b. Refinement - elaboration of detail for all abstractions c. Modularity - compartmentalization of data and function d. Software architecture - Overall structure of the software. e. Control hierarchy f. Software procedure - the algorithms that achieve function
g. Information hiding - controlled interfaces
Abstraction Allow designers to focus on solving a problem without being concerned about irrelevant lower level details. It hides the complexity of the system representing essential features of the system. Enable designer to specify procedure and data and yet suppress low- level details. Levels of abstraction are: Higher level - A solution is stated in broad terms using the language of the problem environment Principles and Practices in Software Development 126
Asia Pacific Institute of Information Technology Lowest level - A more procedural orientation is taken. When source code is generated.
There are two types of abstraction. Procedural abstraction A named sequence of instructions that has a specific and limited function (Pressman, 2005) Example: Login to a website account Open web browser -> type URL -> hit enter -> go to login section -> type Data abstraction 2005) Example: Web site user accounts attributes are Control abstraction Example: Synchronization semaphore used to coordinate activities in an operating system User name, Pass word, User Emil, etc username and password -> click Sign In button
A named collection of data that describes a data objects the data object (pressman,
A program control mechanism without specifying internal details.
Asia Pacific Institute of Information Technology Refinement
Refinement causes the designer to elaborate on the original statement, providing more and more details as each successive refinement (elaboration) occurs. (Pressman, 2005) Help designer to reveal low kevel details as define progresses. Log to website Open web browser -> type URL -> hit enter -> go to login section -> type username and password -> click Sign In button] Add borrow details to inventory BEGIN Get borrow item details from customer Check item availability IF available Let customer to rent it Update rent and inventory files Update customers profile Send confirmation to customer ELSE Reject request ENDIF END
Modularity Software can divide into separate components call modules, which are later combined altogether in order to provide a solution to the problem given. These modules can understand easily by readers rather than reading over large complex program. User no needs to keep track of large number of variables. Modularity can defined as degree which software can be understood by examining its components independently. A problem we meet in day to day life can solve easily by dividing it into sub tasks. This is how modularity gets used in software designing.
Asia Pacific Institute of Information Technology Modular decomposability- if the method of design gives an orderly mechanism for breaking the problems into smaller ones, the complexity will reduce, and thus an effective modular program will be produced. Modular compensability- if the design method allows previously existing designed components to be used in the new system, then a modular solution is ava ilable without the need to redo those once again. Modular under standability- if the module can be used independently without relying on other modules, it will be easy to modify in future. Modular continuity- when changes need to be made in the system req uirements, and if it is possible to make changes within the modules alone rather than throughout the whole system, then it is possible to reduce the problems that occur due to impact of the change. Modular protection- if an unexpected error occurs in one of the modules, the effects of it will be shown within the module, and thus would not have a huge impact on the overall solution. Software architecture Software architecture is the overall structure (Hierarchical structure) of the software components and the ways in which that structure provides conceptual integrity for a system. Properties Architectural Design: Structural properties System components including modules, objects, filters and way they are packaged and Extra-functional properties Design architecture issues related to Performance, capability, reliability, security, Families of related systems adaptability and other system characteristics. interact with each other.
Reusable architectural building blocks use in the system.
(Pressman, 2005)
Asia Pacific Institute of Information Technology Hierarchy chart (Refer13.2 Site Map (Site diagram))
Control hierarchy This is also referred to as the program structure. Represent the module organization and control hierarchy. This is not representing procedural aspects of the software which mean steps of the processes order which decision are made. This is always not suitable to use for every architectural styles. Styles of control hierarchy Treelike diagram Warier-Orr Jackson diagrams
The control hierarchy shows two different features of software architecture: Visibility- refers to the modules that may be invoked or used as data from other components, but not necessarily direct. Connectivity- refers to the modules that are directly invoked or used as data from other components.
Software procedure Focus on the processing of each module individually. According to pressman (2005) a Procedure should provide an accurate specification of processing including sequences of events, decision points, repetitive operations, data organization and structure. This means that the procedural representation of software is layered (Pressman, 2001). Precise module
Asia Pacific Institute of Information Technology Event sequence Decision point Repetitive operations Date organization/structure
Information hiding Controlled interfaces The principle of information hiding is the hiding of design decisions in a computer program that are most likely to change. Information (data and procedure) contained within a module is inaccessible to modules that have no need for such information. Using this methodology function can be separated effectively. According to Pressman (2005), The principal of information hiding suggests that modules need to be characterized by design decisions that (each) hides from all the others. Each of the modules that contain information that has nothing to do with other modules, do not need to see what is taking place internally, inside the other modules. Thus information hiding takes care of this by hiding unnecessary code to other modules. (Pressman, 2005) Software with effective modularity, independent modules easy to develop, easy to maintain, test, error propagation is reduced. It should be used to guide architectural designs, interface designs, and modularization. Modules hide difficult or changeable design decisions
Chapter 13 ARCHITECTURAL DESIGN
A system architecture or systems architecture is the conceptual design that defines the structure and/or behavior of a system. An architecture description is a formal description of a system, organized in a way that supports reasoning about the structural properties of the system. It defines the system components or building blocks and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. This may enable one to manage investment in a way that meets business needs. There is no universally agreed definition of which aspects constitute system architecture, and various organizations define it in different ways. (EventHelix Inc., 2009) The architectural design for the proposed system comprises the following illustrations ranging from the overall architecture, sitemap and the hierarchy diagram.
13.1 Overall Architecture
User
Web Browser
Internet
Firewall
Server
Database
ASP Script
ASP Interpreter
Bridge Client
Bridge Server
Driver Manager
SQL Database
Asia Pacific Institute of Information Technology These two diagrams represent 2 aspects of the architecture. The architecture for the proposed web based system is a client-server architecture where the client access internet and web server from the web browser In overall architecture the user is represented from the top level of the diagram which is the External Level that illustrates the user view/ interface. The server side is represented from the bottom level of the diagram, which is in the internal/ physical level of the architecture. As implemented in the proposed system, in the developers point of view, the developer needs to run Visual Studio software to develop the website offline.
13.2 Site Map (Site diagram)

Home My Profile
Parental Control Info Buy Action / Adventure Animated Foreign Comedy Rent Rent
Buy
Movies
Drama Family and Kids Horror Sci-Fi / Fantasy Spots and Fitness Action / Adventure Education
Games
Puzzle Racing Shooting Family and Kids Sports
Rock and Pop Classical
Songs
Jazz and Blues Children Drama
Comments
13.3 Hierarchy Chart
Delta Entertainments
Login
Guest Home My Profile Movies Games Songs Comments
Admin Home Movies Games Songs Reports
Staff Home Movies Games Songs
User Home My Profile Movies Games Songs Comments
Chapter 14 INTERACTIVE SCREEN DESIGN
Home Page
Asia Pacific Institute of Information Technology Registration Page
Asia Pacific Institute of Information Technology My Profile Page
Asia Pacific Institute of Information Technology Parental Control
Asia Pacific Institute of Information Technology Movies Page
Asia Pacific Institute of Information Technology Movie Info Page
Asia Pacific Institute of Information Technology Games Page
Asia Pacific Institute of Information Technology Songs Page
Asia Pacific Institute of Information Technology Comments Page
Asia Pacific Institute of Information Technology Rent Page
Asia Pacific Institute of Information Technology Purchase Page
Asia Pacific Institute of Information Technology Staff and Admin Home Page
Asia Pacific Institute of Information Technology Staff and Admin Movie Page
Asia Pacific Institute of Information Technology Admin Reports Page
Chapter 15 REPORT DESIGN
Inventory
Address
xxxxxxx xxxxxxx xxxxxxx xxxxxxx
Date:
Inventory
Item ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Name xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Item Type xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
No_of_copies (In hand) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
No of copies (Sold) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Price xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Purchased
Address
Date:
Purchased
Purchased ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Receipt ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Member ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Purchase Date xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Price xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Rented
Address
Date:
Rent
Rent ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Member ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Rent Date xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Fine xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Return Date xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Income
Address
Date:
Income
Income ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Month ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Items Sold xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Items Rent xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Income xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Members
Address
Date:
Members
User ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
User Name xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Last Activity xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Account Type xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Requests
Address
Date:
Resuests
Request ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Item Name xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Item Type xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Description xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Date of Request xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Fine
Address
Date:
Fine
Fine ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Rent ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Overdue xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Amount xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Chapter 16 PROGRAMMING ENVIRONMENT
The programming language chosen to be used for the project was ASP.Net with C#. ASP.net allows developing web applications which interacts with a database. Also it supports to implement many functionalities and it consists with many programming tool therefore it enables make the development process faster. (Exforsys Inc., 2010)
Advantages, which include: speed stability high security Easiness in learning and using open source- can obtain free scripts with required functionality
This also supports XML , use authentication schemes, cache frequently used data and customize application's configuration.( Exforsys Inc.,2010)
Since it is free, easy to learn, and works well with several platforms and software programs, it was identified as the most suitable to use for the project.
Chapter 17 TESTING
17.1 Test Plans for User & Guest Input/output
The development process involves various types of testing. Each test type addresses a specific testing requirement. The most common types of testing involved in the development process are: Unit Test. System Test Integration Test Functional Test Performance Test Beta Test Acceptance Test.
Unit Test The first test in the development process is the unit test. Unit test depends upon the language on which the project is developed. Unit tests ensure that each unique path of the project performs accurately to the documented specifications and contains clearly defined inputs and expected results.
System Test Several modules constitute a project. If the project is long-term project, several developers write the modules. Once all the modules are integrated, several errors may arise. The testing done at this stage is called system test. Principles and Practices in Software Development 158
Asia Pacific Institute of Information Technology Functional Test Functional test can be defined as testing two or more modules together with the intent of finding defects, demonstrating that defects are not prese nt, verifying that the module performs its intended functions as stated in the specification and establishing confidence that a program does what it is supposed to do.
Acceptance Testing Testing the system with the intention of confirming readiness of the product and customer acceptance. (Exforsys Inc., 2009)
Unit testing is used for test the application. It should include the testing of each and every feature. Following are the Charles' Six Rules of Unit Testing: 1. Write the test first 2. Never write a test that succeeds the first time 3. Start with the null case, or something that doesn't work 4. Don't be afraid of doing something trivial to make the test work 5. Loose coupling and testability go hand in hand 6. Use mock objects Each unit is tested separately before integrating them into modules to test the interfaces between modules. Every detail of the test should be clearly visible to the person reading the documentation. (Burback R.,1998)
Asia Pacific Institute of Information Technology Common Buttons Test case 1 Description Clicking the button 2 Clicking the My Goes to My profile page OK OK Expected outcome Actual outcome OK
Home Goes to Home page
Profile button 3
Clicking the Movie Goes to Movie page button
Clicking the Games Goes to Games page button
OK
Clicking the Songs Goes to Songs page button
OK
Clicking Comments button
the Goes to Comments page
OK
Clicking the Logout Goes to the respective button page
OK
Asia Pacific Institute of Information Technology Home Page Test case 1 Description Username is NULL Expected outcome Display Please enter user name* 2 Password is NULL Display Please enter Password * 3 Clicking button 4 Username Password is wrong the login Goes to the respective main page or Display Your login attempt again * was not successful. Please try OK OK OK Actual outcome OK
My Profile page when not logged in Test case 1 Description Username is NULL Expected outcome Display Please enter user name* 2 Password is NULL Display Please enter Password * 3 Clicking button 4 Username Password is wrong the login Goes to the respective main page or Display Your login attempt was not successful. Please try OK OK OK Actual outcome OK
Asia Pacific Institute of Information Technology again * 5 Clicking the Sign-up Goes to Registration button page OK
My Profile page Test case 1 Description Expected outcome Actual outcome NO
Clicking the Renew It renews the return buttons due date the Loan It shows the summary Click Goes to the Parental control page loan
Clicking
NO
History button 3 Clicking the
OK
Here button
Movies / Games and Songs Pages Test case 1 Description Clicking respective buttons 2 Clicking button 3 the Info Goes to the respective page OK OK Expected outcome the Goes to the respective category pages Actual outcome OK
Clicking the Sign-up Goes to Registration button page the Buy Goes to the purchase
Clicking
OK
Asia Pacific Institute of Information Technology button 5 Clicking button the page Rent Goes to Rent page OK
About the Movie page Test case 1 Description Expected outcome add to the the Actual outcome OK
Clicking the Submit Should button comment
comments panel 2 Clicking button 3 Clicking button 4 Clicking button the Back Goes to the Movie page OK the the Buy Goes to the purchase page Rent Goes to the Rent page OK OK
Purchase page Test case 1 Description Expected outcome send the Actual outcome NO
Clicking the Purchase Should button
details to the company the Buy Goes to the purchase page OK
Clicking button
Asia Pacific Institute of Information Technology 3 Clicking button 4 Clicking button the Back Goes to the respective page OK the Rent Goes to Rent page OK
Rent page Test case 1 Description Clicking button 2 Clicking button the the Expected outcome Rent Should send the Actual outcome NO
details to the company Back Goes to the respective page OK
Comments Page Test case 1 Description Expected outcome send the Actual outcome NO
Clicking the Submit Should button
feedback to the admin
Parental Control Page Test case 1 Description Clicking button 2 Clicking the the Expected outcome Add Should add the child ID Save Should save the child NO Actual outcome NO
Asia Pacific Institute of Information Technology button 3 Clicking the details Up Should add the child ID Add Should block the NO NO
Grade button 4 Clicking button 5 the
selected Items NO
Clicking the Renew It renews the return buttons due date the Loan It shows the summary Back Goes to the My loan
Clicking
NO
History button 7 Clicking button the
OK
Profile page
Registration Page Test case 1 Description Clicking button 2 the Expected outcome Back Goes to My profile page NO Actual outcome OK
Clicking the Check Should check the user availability button name is available or not
Clicking the Verify Should button
checks
the
NO
Credit card number and the pin number is valid
17.2 Test Plans for Administrator & Staff Input/output
Common Buttons Test case 1 Description Clicking the button 2 Clicking the Movie Goes to Movie page button 3 Clicking the Games Goes to Games page button 4 Clicking the Songs Goes to Songs page button 5 Clicking the Reports Goes to Reports page button 6 Clicking the Logout Goes to the respective button page OK OK OK OK OK Expected outcome Actual outcome OK
Home Goes to Home page
Asia Pacific Institute of Information Technology Movies / Games and Songs Pages Test case 1 Description Clicking button the Expected outcome Edit Should be able to edit the data in to grid view 2 Clicking the Delete Should button be able to NO Actual outcome NO
delete the data in to grid view
Clicking the Browse Should button
be able to
OK
select a picture be able to NO
Clicking the Upload Should button
upload the selected picture
Clicking button
the
Clear Should
be able to
NO
clear the data in the text boxes
Clicking button
the
Save Should be able to save the data in the data base and show then in the grid view
NO
Asia Pacific Institute of Information Technology Reports Page Test case 1 Description Expected outcome Actual outcome NO
Clicking the Search Should be able to sort from button the category the data by category
Clicking the Search Should be able to sort from button Time Period the data by the Time Period the Goes to the respective category pages
NO
Clicking respective buttons
OK
REFERENCES
Centers for Medicare and Medicate Services, (2008), Selecting a Development Approach, [online] available from http://www.cms.hhs.gov/SystemLifeCycleFramework/downloads/SelectingDevelopmentApproa ch.pdf [accessed on 20th December 2009] Alexandrou, (2010), Rapid Application Development,[online] available from http://www.mariosalexandrou.com/methodologies/rapid-application-development.asp [ accessed on 23rd December 2009] Shelly G.B., Cashman T.J., Rosenblatt H.J., (2001) System Analysis and Design, 4th ed. Anon.,(n.d.),The Software Development Life Cycle (SDLC),For Small To Medium Database Applications[online] available from http://www.elucidata.com/refs/sdlc.pdf [accessed on 26th December 2009] Agile Methodology Organization, (2010), The Agile Methodology, [online] available from http://agilemethodology.org/about/ [accessed on 25th December 2009] Sudarsan iTech Pvt Ltd, (n.d.),Agile Methodology Development [online] available from http://www.sudarsantechnologies.com/methodology.html [accessed 1st of January 2010] Tarigan A., (n.d.), Software Engineering Part II, Project Management & Risk Manage ment, Gunadarma University Pressman R., (2001), Software Engineering: A practitioner's Approach, 6th Ed. Department of Energy Quality Managers Software Quality Assurance Subcommittee (1999), Software Risk Management Practical Guide Chapman J.R., (1997), what is project management [online] available from http://www.hyperthot.com/pm_intro.htm [accessed on 4th of January 2010] Crane L.M.,(2002), Software Characteristics,[online] available from http://74.125.153.132/search?q=cache:8BtTy03i08YJ:tarpit.rmc.ca/cficse/2002/lectures/SF/sf04. ppt+characteristics+software&cd=12&hl=en&ct=clnk&gl=lk [ accessed on 15th January 2010] Sommerville I.,(2004), Software Engineering, 7th edition Gkmen M.(n.d.), Design Concepts and Principles, [online] available from http://www3.itu.edu.tr/~gokmen/SE-lecture-6.pdf [accessed 2nd February 2010] Principles and Practices in Software Development 169
Asia Pacific Institute of Information Technology Exforsys Inc., (2010) ASP.NET with C# Training Launch [Online], Available from: http://www.exforsys.com/tutorials/asp.net/asp.net-with-csharp-training.html [Accessed on 15 January 2010] EventHelix Inc., (2009),System Architecture design examples [online], available from http://www.eventhelix.com/EventStudio/spaceport_system_architecture_design/ [accessed 5th February 2010] Burback R.,(1998) Unit Testing, [online] available from
http://infolab.stanford.edu/~burback/watersluice/node22.html [ accessed on 5th Februru 2010] Anon, (n.d.),what is configuration management?, [online] available from http://www.pearsonhighered.com/assets/hip/us/hip_us_pearsonhighered/samplechapter/0321117 662.pdf [ accessed 3rd february 2010]
APPENDICES
A. User Manual
Home Page
Click this button if you want to view the Click this button if you want to view the home page movies page Click this button if you want to view the games page Click this button if you want to view the My Profile page Click this button if you want to register to the website Click this button if you want to login to the Click this button if you want to view the comments page Click this button if you want to view the songs page
Asia Pacific Institute of Information Technology Registration Page Click this button if you want to go back to the my profile page
Click this button if you want to check whether the user name is available
Click this button if you want to get register
Asia Pacific Institute of Information Technology Click this button if My Profile Page you want to logout from the website
Click this button if you want to login to the website
Click this button if you want to register to the website
Click this button if you want to renew your item
Click this button if you want to see the loan history
Click this button if you want to see your Principles and Practices inchilds account Software Development 173
Asia Pacific Institute of Information Technology Parental Control Click this button if you want to go back to my profile page Click this button if you want to add a child Click this button if you want to save your child details
Click this button if you want to block the selected categories for your child Click this button if you want to renew your childs item Click this button if you want to see your childs loan history
Asia Pacific Institute of Information Technology Movies / Games and Songs Pages
Click these buttons if you want to select the categories Click this button if you want to see the information about Click this button if you want to register to the website the item Click this button if you want to buy the item
Click this button if you want to rent the item
Asia Pacific Institute of Information Technology button if Click this you want to go back Movie Info Page to movie page
Click this button if you want to add a comment
Asia Pacific Institute of Information Technology Comments Page
Click this button if you want to add a comment or a rating
Asia Pacific Institute of Information Technology Click this button if Rent Page you want to go back to the item page
Click this button if you want to rent the item
Click this button if Purchase Page you want to go back to the item page
Click this button if you want to purchase the item
Asia Pacific Institute of Information Technology Staff and Admin Home Page
Click this button if you want to delete an Click this button if you want to edit an entry entry
Asia Pacific Institute of Information Technology Staff and Admin Movie / Games and Songs Pages
Click this button if you want to select a picture
Click this button if you want to upload the picture
Click this button if you want to clear the text boxes
Click this button if you want to save the data in the database
Asia Pacific Institute of Information Technology Admin Reports Page
Click these buttons if you want to view the reports by categories
Click these buttons if you want to sort the report by categories
B. Questionnaire
1. What is your age group? a. Below 18 b. 18-30 c. 30-45 d. Above 45 2. What is your country? a. Asian b. European 3. What is the language you prefer for communication? a. English b. Tamil c. Sinhala 4. What is your internet connection? a. ADSL/DSL b. Dial- up 5. In what ways do you like to provide feedback?(you can select multiple answers) a. Online Textual feed backs b. Emails subscribes c. Submit comments by a call d. Submit comments by DEC website via Online Rating system e. Submit comments by DEC website via textual comments f. Visit DVC shop and do
6. How do you prefer to buy/ rent items? a. Online b. Visit and buy 7. How do you like to buy CD/DVDs? a. Visit DVC shop and buy b. Order online and ask to deliver items to home Principles and Practices in Software Development 182
Asia Pacific Institute of Information Technology c. Buy and download them at the same time 8. How do you like do your online payments? a. Pay using a credit card b. Use PayPal account c. By using DVC account and paying the sum at the end of the month 9. How do you download CD/DVDs? a. Direct file download b. Download as torrents c. Online Streaming 10. How do like to submit requests for new items? a. Visit and ask directly from the DVC center b. Email to us c. Request using your DVC account on our website d. Call to DVC call center and request 11. How do you like to check due date for our rented items? a. Log using your DVC account and check due dates b. Call to our call service and check c. Receive an email from us before few days of rent period expire d. You dont want; you monthly check the receipt and return 12. How do you like to request for a rental extending? a. Log into DVC web site and renew it b. Call and ask from our call service c. Visit DVC and renew it d. Email to DVC 13. How do you like to use parental control on items ( for your children) ? a. Buy a family package and giving separate permissions to members b. Want to block items separately c. Want to put time barrier for their next borrows d. Whenever they request, you want instance massage. Till you confirm it, they cant borrow. 14. As a DVC customer your favourite communication methods with us ? Principles and Practices in Software Development 183
Asia Pacific Institute of Information Technology a. Using our website to contact us b. Using email service c. Using traditional manual methods d. Using our call center 15. How do you like to see new items in our DVC ? a. Email about all new items to you b. Show our new items in your home page in our website c. Submit it to your social network account, twitter or any favorite 16. Why do you want to have parental control ? a. Limit your childrens Entertaining hours b. Limit to access various categories
c. Make their favors according to your choice 17. Do you like to give your new ideas ?
Thank you for your participation
C. Questionnaire Summary

PPSP

Uploaded by

Copyright:

Available Formats

You might also like

PPSP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PPSP

Uploaded by

Copyright:

Available Formats

Submitted By: Charith Devaka Sooriyaarachchi Shanil Fernando Maheeka Jayasuriya CB003344 CB002723 CB003346

Submitted To: Mr. Shanaka de Silva

Intake Code: HF09B1SE / HF0981MM

Assignment Title: Delta Entertainment Company Online System

Date Due: 12th February 2010

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development

Asia Pacific Institute of Information Technology

Chapter 1 PROJECT BRIEF ING

Principles and Practices in Software Development

Asia Pacific Institute of Information Technology

1.2 Problem Background

Principles and Practices in Software Development

Asia Pacific Institute of Information Technology

1.3 Proposed Solution

Principles and Practices in Software Development 10

Asia Pacific Institute of Information Technology

Chapter 2 SCHEDULE PLANNING

Principles and Practices in Software Development 11

Asia Pacific Institute of Information Technology

2.2 PERT Chart (Activity Network)

Principles and Practices in Software Development 12

Asia Pacific Institute of Information Technology

2.3 Workload Matrix

Principles and Practices in Software Development 13

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 14

Asia Pacific Institute of Information Technology

Chapter 3 SELECTION OF METHODOLOGY

1.1 Identification of methodologies

Principles and Practices in Software Development 16

Asia Pacific Institute of Information Technology

Figure 1: Waterfall model (Source: Pressman R., 2003)

Principles and Practices in Software Development 17

Asia Pacific Institute of Information Technology

Figure 2: Incremental model (Source: Pressman R., 2003)

Principles and Practices in Software Development 18

Principles and Practices in Software Development 19

Asia Pacific Institute of Information Technology

Figure 3: Rapid Application Development (Source: Pressman R., 2003)

Principles and Practices in Software Development 20

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 22

Principles and Practices in Software Development 23

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 24

Principles and Practices in Software Development 25

Principles and Practices in Software Development 26

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 28

Asia Pacific Institute of Information Technology

Figure 6: Agile Development Methodology

Principles and Practices in Software Development 29

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 30