P. 1
PPSP

PPSP

|Views: 250|Likes:
Published by Maheeka Jayasuriya
Principles and Practices in Software Production
Principles and Practices in Software Production

More info:

Published by: Maheeka Jayasuriya on Apr 02, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF or read online from Scribd
See more
See less

10/14/2014

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

4

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development

5

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development

6

Asia Pacific Institute of Information Technology

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 children‟s accounts (both purchases and rentals)

Principles and Practices in Software Development

8

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development

9

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
2.1 Gantt Chart

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
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

Principles and Practices in Software Development 13

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 14

Asia Pacific Institute of Information Technology
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

 

Principles and Practices in Software Development 16

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development 17

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 18

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)

Principles and Practices in Software Development 19

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development 20

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

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 22

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.

Principles and Practices in Software Development 23

Asia Pacific Institute of Information Technology

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 aren‟t 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

Principles and Practices in Software Development 24

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

Principles and Practices in Software Development 25

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.)

Principles and Practices in Software Development 26

Asia Pacific Institute of Information Technology

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, there‟s 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

Principles and Practices in Software Development 28

Asia Pacific Institute of Information Technology

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 software‟s internal structure.

Principles and Practices in Software Development 29

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 30

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.

Principles and Practices in Software Development 32

Asia Pacific Institute of Information Technology

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 shouldn‟t 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 shouldn‟t 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 isn‟t appropriate we haven‟t 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.

Principles and Practices in Software Development 33

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.

Principles and Practices in Software Development 34

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 isn‟t 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 doesn‟t 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 doesn‟t 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.

Principles and Practices in Software Development 36

Asia Pacific Institute of Information Technology

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. That‟s 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.

Principles and Practices in Software Development 38

Asia Pacific Institute of Information Technology

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 project‟s 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

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development 41

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 project‟s 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

Principles and Practices in Software Development 42

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

Principles and Practices in Software Development 44

Asia Pacific Institute of Information Technology

4.3 Risk Management Plan

Principles and Practices in Software Development 45

Asia Pacific Institute of Information Technology

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 administrator‟s 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.

Principles and Practices in Software Development 49

Asia Pacific Institute of Information Technology Document structure This has a major impact to user‟s usability and readability since that‟s 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))

Principles and Practices in Software Development 50

Asia Pacific Institute of Information Technology Sample document cover page

Principles and Practices in Software Development 51

Asia Pacific Institute of Information Technology

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

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development 54

Asia Pacific Institute of Information Technology

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. Doesn’t ware out

As pressman mentioned early in his book (pressman, p.6) software doesn‟t 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.

Principles and Practices in Software Development 55

Asia Pacific Institute of Information Technology

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 writer‟s 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.

Principles and Practices in Software Development 56

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.

Principles and Practices in Software Development 57

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)

Principles and Practices in Software Development 58

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

Principles and Practices in Software Development 59

Asia Pacific Institute of Information Technology

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 they‟re going to arrange the staff whether in groups or individually and how to develop their skills to complete the plan.

Principles and Practices in Software Development 61

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

Principles and Practices in Software Development 65

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 doesn‟t 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

Principles and Practices in Software Development 66

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

Principles and Practices in Software Development 67

Asia Pacific Institute of Information Technology
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.

Principles and Practices in Software Development 68

Asia Pacific Institute of Information Technology

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

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 70

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 71

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 72

Asia Pacific Institute of Information Technology
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. Parkinson‟s‟ 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.

Principles and Practices in Software Development 74

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 system‟s 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 it‟s hard to find a system that‟s 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

Asia Pacific Institute of Information Technology

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, X2…X3, Xn) Parkinson‟s‟ 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 it‟s hard to recommend this as a good technique.

Pricing to win Estimation model depend on the customers budget and don‟t care the systems functionality.

Principles and Practices in Software Development 76

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 77

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

Principles and Practices in Software Development 78

Asia Pacific Institute of Information Technology

Chapter 8 REQUIREMENT ANALYSIS

Principles and Practices in Software Development 79

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 80

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 81

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 82

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 83

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 84

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 85

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 86

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 87

Asia Pacific Institute of Information Technology

Principles and Practices in Software Development 88

Asia Pacific Institute of Information Technology

Chapter 9 PROCESS MODELLING
9.1 Context Diagram

Principles and Practices in Software Development 89

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

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 90
Disapproved request Parent

Sales reports Lends reports Requests reports Members reports

Owner

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 91

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

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 92

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

Principles and Practices in Software Development 93

Asia Pacific Institute of Information Technology DFD 3.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

Principles and Practices in Software Development 94

Asia Pacific Institute of Information Technology DFD 4.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

Principles and Practices in Software Development 95

Asia Pacific Institute of Information Technology DFD 5.0

Owner

Item details

5.1 Update inventory

Item details

5.2 Receive item details

Item details

D1 Inventory

Figure 17: DFD 5.0

Principles and Practices in Software Development 96

Asia Pacific Institute of Information Technology DFD 6.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

Principles and Practices in Software Development 97

Asia Pacific Institute of Information Technology DFD 7.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

Asia Pacific Institute of Information Technology DFD 8.0

Customer

Feedback 8.1 Receive feedback

Structured feedback Feedback 8.2 Process feedback

D6 Feedbacks

Figure 20: DFD 8.0

Principles and Practices in Software Development 99

Asia Pacific Institute of Information Technology

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

Number Name Description

3.5 Calculate fine When an item‟s 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

Number Name Description

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

Principles and Practices in Software Development 100

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 101

Asia Pacific Institute of Information Technology
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 parent‟s membership records Else Create a non-member parent record for parent

Principles and Practices in Software Development 102

Asia Pacific Institute of Information Technology

Chapter 10 DATA MODELLING
10.1 Entity Relationship Diagram

Principles and Practices in Software Development 103

Asia Pacific Institute of Information Technology
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

Principles and Practices in Software Development 104

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 105

Asia Pacific Institute of Information Technology

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

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 107

Asia Pacific Institute of Information Technology

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

Name Description Input Data Flows

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

Name Description Input Data Flows

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

Name Description Input Data Flows

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

Name Description Input Data Flows

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

Name Description Input data flows Output data flow Data structure

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

Name Description Input data flows Output data flow Data structure

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

Name Description Input data flows Output data flow Data structure

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)

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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

Asia Pacific Institute of Information Technology

Name Description Origin/Source Destination/Sink Data structure

Lending details Gives the lend details to the customer 1.4 Lend item Customer = Item ID + Due date

Name Description Origin/Source Destination/Sink Data structure

Request renewal Customer request to extend loan Customer 4.2 Receive renewal request = Item ID + Member ID

Name Description Origin/Source Destination/Sink Data structure

Renewal details Gives the renewal details to the customer 4.3 Renew item Customer =Item ID + extended due date

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

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}

Name Description Origin/Source Destination/Sink Data structure

Parent details Provides the parental details to the system Customer 7.3 Handle underage customer details = Name + Email + NIC Number + Address + Telephone no. + (parent‟s membership ID )

Name Description Origin/Source Destination/Sink Data structure

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

Name Description Origin/Source Destination/Sink Data structure

Request new item Customer makes requests for new items from the system Customer 6.1 Receive new item request =Item Name + Item type+ description

Name Description Origin/Source Destination/Sink Data structure

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}

Principles and Practices in Software Development 120

Asia Pacific Institute of Information Technology

Chapter 12 DESIGN PRINCIPLES AND CONCEP TS

12.1 Design Principles and Concepts

This is an engineering representation of tracing customer‟s requirements in predefined criteria to certify quality of product. Software design is the only phase that customer‟s requirements are fully transferred into a finished software product. Furthermore, this is the only phase in which the customer‟s 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 it‟s 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

Asia Pacific Institute of Information Technology

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)

Principles and Practices in Software Development 122

Asia Pacific Institute of Information Technology

Design Principles
According to pressman design model is equivalent to the architect‟s 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

Principles and Practices in Software Development 123

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.

Principles and Practices in Software Development 125

Asia Pacific Institute of Information Technology

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 account’s 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.

Principles and Practices in Software Development 127

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 customer‟s 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.

Principles and Practices in Software Development 128

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)

Principles and Practices in Software Development 129

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

Principles and Practices in Software Development 130

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

Principles and Practices in Software Development 131

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 132

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 developer‟s point of view, the developer needs to run Visual Studio software to develop the website offline.

Principles and Practices in Software Development 133

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 134

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 135

Asia Pacific Institute of Information Technology

Chapter 14 INTERACTIVE SCREEN DESIGN

Home Page

Principles and Practices in Software Development 136

Asia Pacific Institute of Information Technology Registration Page

Principles and Practices in Software Development 137

Asia Pacific Institute of Information Technology My Profile Page

Principles and Practices in Software Development 138

Asia Pacific Institute of Information Technology Parental Control

Principles and Practices in Software Development 139

Asia Pacific Institute of Information Technology Movies Page

Principles and Practices in Software Development 140

Asia Pacific Institute of Information Technology Movie Info Page

Principles and Practices in Software Development 141

Asia Pacific Institute of Information Technology Games Page

Principles and Practices in Software Development 142

Asia Pacific Institute of Information Technology Songs Page

Principles and Practices in Software Development 143

Asia Pacific Institute of Information Technology Comments Page

Principles and Practices in Software Development 144

Asia Pacific Institute of Information Technology Rent Page

Principles and Practices in Software Development 145

Asia Pacific Institute of Information Technology Purchase Page

Principles and Practices in Software Development 146

Asia Pacific Institute of Information Technology Staff and Admin Home Page

Principles and Practices in Software Development 147

Asia Pacific Institute of Information Technology Staff and Admin Movie Page

Principles and Practices in Software Development 148

Asia Pacific Institute of Information Technology Admin Reports Page

Principles and Practices in Software Development 149

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 150

Asia Pacific Institute of Information Technology

Purchased

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

Date:

Purchased

Purchased ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

Item 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

Principles and Practices in Software Development 151

Asia Pacific Institute of Information Technology

Rented

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

Date:

Rent

Rent ID xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

Item 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

Principles and Practices in Software Development 152

Asia Pacific Institute of Information Technology

Income

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

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

Principles and Practices in Software Development 153

Asia Pacific Institute of Information Technology

Members

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

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

Principles and Practices in Software Development 154

Asia Pacific Institute of Information Technology

Requests

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

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

Principles and Practices in Software Development 155

Asia Pacific Institute of Information Technology

Fine

Address

xxxxxxx xxxxxxx xxxxxxx xxxxxxx

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

Principles and Practices in Software Development 156

Asia Pacific Institute of Information Technology

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.

Principles and Practices in Software Development 157

Asia Pacific Institute of Information Technology

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)

Principles and Practices in Software Development 159

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

4

Clicking the Games Goes to Games page button

OK

5

Clicking the Songs Goes to Songs page button

OK

6

Clicking Comments button

the Goes to Comments page

OK

7

Clicking the Logout Goes to the respective button page

OK

Principles and Practices in Software Development 160

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

Principles and Practices in Software Development 161

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

2

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

4

Clicking

OK

Principles and Practices in Software Development 162

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

2

Clicking button

Principles and Practices in Software Development 163

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

Principles and Practices in Software Development 164

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

6

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

3

Clicking the Verify Should button

checks

the

NO

Credit card number and the pin number is valid

Principles and Practices in Software Development 165

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 166

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

3

Clicking the Browse Should button

be able to

OK

select a picture be able to NO

4

Clicking the Upload Should button

upload the selected picture

5

Clicking button

the

Clear Should

be able to

NO

clear the data in the text boxes

6

Clicking button

the

Save Should be able to save the data in the data base and show then in the grid view

NO

Principles and Practices in Software Development 167

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

2

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

3

Clicking respective buttons

OK

Principles and Practices in Software Development 168

Asia Pacific Institute of Information Technology

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 GÖkmen 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]

Principles and Practices in Software Development 170

Asia Pacific Institute of Information Technology

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

Principles and Practices in Software Development 171

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

Principles and Practices in Software Development 172

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 inchild‟s 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 child‟s item Click this button if you want to see your child‟s loan history

Principles and Practices in Software Development 174

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

Principles and Practices in Software Development 175

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

Principles and Practices in Software Development 176

Asia Pacific Institute of Information Technology Comments Page

Click this button if you want to add a comment or a rating

Principles and Practices in Software Development 177

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

Principles and Practices in Software Development 178

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

Principles and Practices in Software Development 179

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

Principles and Practices in Software Development 180

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

Principles and Practices in Software Development 181

Asia Pacific Institute of Information Technology

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 don‟t 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 can‟t 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 children‟s 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

Principles and Practices in Software Development 184

Asia Pacific Institute of Information Technology

C. Questionnaire Summary

Principles and Practices in Software Development 185

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->