PROJECT MANAGEMENT(SCHEDULING)

TIMELINE CHARTWork Tasks

Identify needs and requirementsSetting goalsDefining user characteristicsIdentify project constraintsMilestone: Product statement definedIdentify problem statementDefine problem statementAlternative solutionsMilestone: Problem definedData flow diagramER diagramUse case diagramMilestone: Models DesignedIdentify Technical FeasibilityIdentify Econimic FeasibilityIdentify Operational FeasibilityMilestone: Feasibility IdentifiedComponent level designProduct estimationEstimate RiskTesting

Week 6Week 1 Week 2 Week 3 Week 4 Week 5

RISK MANAGEMENT

• RISK TABLESynod Risks Involved Impact Category Probability Mitigation Measures

1. Technology will not meet expectations

High(1) TE 30% Replace potentially defective components with bought-in components of known reliability.

2. Staff inexperienced

Low(2)

ST

30%

Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs.

3. Lack of training on tools.

Low(3) DE 80% Organize workshops, seminars to train the staff

4. Larger number of users than planned

Low(3) PS 30% Make a high performance plan that efficient for users.

5. Funding will be lost Low(3) CU 50% Regular conduct seminars to

ensure that we are not running out of resources

6. Delivery Deadline will be tightened

Low(2) BU 40% Work within time period schedule, cross check your progress meanwhile

7. Documentation Risk

Negligible(4)

PD 20% Define documentation standards and regularly supervise documents developed in timely manner.

8. Code may not execute in a proper manner

Low(2) TE 30% Make code in a modular manner such that each segment is independent

FUNCTION POINTS (FP)

S.No.

Domain Values Count Weighting Factor(Simple)

1. External Inputs (EIs) 5 * 3 = 152. External Outputs (EOs) 4 * 2 = 83. External Inquiries (EQs)

3 * 4 = 12

4. Internal Logical Files 8 * 3 = 245. External Interface Files 2 * 5 = 10 Count Total = 49

COMPUTING FUNCTION POINTS FP = total count × [0.65 + 0.01 × Σ (Fi)] All the values of simple weighting factors are assumed.Where total count is the sum of all FP entries obtained in table below: • External Inputs: - User (Police officers) and programmer. • External Outputs: - Crime Record Management system and advance uses. • External inquiries: - Queries generated by system like search a victim. • Internal Logical file:- Database Files, Hex file • External Logical files:-. Hex file used by another application such as database management system to maintain records.

EFFORTS • A typical estimation model is derived using regression analysis on collected from past software projects. • Where E is the effort in person-months, FP is the Function Point count:• • E = -91.4 + 0.355 * FP (Albert and Gaffney Model) • = -91.4 + 0.355 * 51.3 • = -73.1885• • E = -37 + 0.96*FP (Kemmerer Model) • = -37+0.96*51.3• = 12.248• • E = -12.88 + 0.405*FP (Small Project Regression Model) • = -12.88 + 0.405 * 51.3• = 7.8965• • For this project-• Function points estimated = 51.3 • Therefore, the effort expended over the entire life cycle for software development and maintenance: • • E = (-37 + (0.96×51.3)) • = 12.248 person-hours • • Effort estimated = 12 person-hours (approx.)

SYSTEM DESIGN

INTRODUCTION

• Software design sits at the technical kernel of the software engineering process and is applied regardless of the development paradigm and area of application. Design is the first step in the development phase for any engineered product or system. The designer’s goal is to produce a model or representation of an entity that will later be built. Beginning, once system requirement have been specified and analyzed, system design is the first of the three technical activities -design, code and test that is required to build and verify software.

SCOPE• The most challenging and creative phase of the system life cycle is

SYSTEM DESIGN. It shows how the software system will be structured to satisfy the requirements identified in the SRS. It refers to the technical specifications that will meet the stated requirements. The design specifications that get generated at the end of this phase are technical in nature and are the blueprint for the implementation activity.

• Thus the scope of SDD encompasses:-• • User interface• Manual procedure• Data base design• Program structure

DATA DESIGN

INTRODUCTION COMPONENT LEVEL DESIGN

This document consists of state transition diagram,control specification document,

process specification.

INTERFACE DESIGNThis document consists of state transition diagram, control specification document,

process specification.

ARCHITECTURAL DESIGNThis document in software design document consists of data flow diagrams and architectural styles (Data

flow architecture).

DATA DESIGNThe data design consists of entity relationship diagram, data

dictionary data structures and data modeling.

DATA MODELLING

DATA OBJECTS AND THEIR RELATIONSHIPS

S.NO.

RELATIONSHIP

PARTICIPATING ENTITIES

1.

Involved in

CASE CRIMINAL

2.

Lodged by

CASEVICTIM

3.

Have

CASE CRIME

DATA OBJECTS AND THEIR ATTRIBUTESS.NO. ENTITY ATTRIBUTES

1. CASE Case_idIPCAreaDate TimeStatusCrimeDamage

2. CRIMINAL C_idCase_idNameSexHeightWeightChargesDOB

3. VICTIM IdNameSexPan_No.AddressCase_idDOB

4. CRIME Crime_idCrime

DATA DICTIONARY Table Name Field Name Data Type Description Example

Victim id Varchar(40) Id of the Victim 1123abhi2134

Name char(40) Name of the Victim Edward Cullen

Sex Char(6) Sex of the victim Male

Pan_no Integer(10) Pan Card Number Of the Victim 1100986754

Address Varchar(40) Address of the Victim 7d DDA SFS flats skylark apartment Gazipur New Delhi

Case_id Varchar(40) Case Identity Of the Victims Case 12345db

dob Date Date of birth of the Victim 08/11/1995

age Integer(2) Age Of Victim 17

Criminal C_id Varchar(40) Identity of criminal 123hh45

Case_id Varchar(40) Case identity of the case for which criminal is convicted F2345caraccident1234

name char(20) Name of the criminal Isabella Swan

sex char(6) Sex of the criminal Female

height Integer(3) Height of the criminal in cm 180

weight Integer(3) Weight of criminal in kgs 40

charges Varchar(50) Charges on criminal Murder

dob Date Date of birth of criminal 11/11/1995

age Integer(2) Age of criminal 18

Crime Crime_id Varchar(40) Crime Identity 43caraccident123

crime Char(50) Crime committed Extortion

Cases date time Date, Time Date and time of case 11:00 am 14/11/2008

area Varchar(40) Area related to that case Sanket apartment Vasundhara enclave

IPC Varchar(40) Indian Penal Code Section 51

case_identity Varchar(40) Id number of case 1234db13

status Varchar(40) Status of the case Pending

crime Varchar(40) Type of crime Murder

damage Integer(10) Contains cheque number 1230500600

ENTITY RELATIONSHIP DIAGRAM

ARCHITECTURAL DESIGN

DATA FLOW DIAGRAMS

DATA FLOW DIAGRAMS

USE CASES

TESTING

OBJECTIVE

• Software testing is a process conducted to provide stakeholders with details about the quality of the product or service under test. It can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).

OBJECTIVE (CONTINUED)• White-box testing also called glass-box testing is a test case design

method that uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can test cases that

• Guarantee that all independent paths within in a module have been exercised at least once.

• Exercise all logical decisions on their true and false sides.• Execute all loops at their boundaries and within their operational

bounds.• Exercise internal data structures to ensure their validity.• The various white-box testing techniques are:• Basis path Testing• Control Structure Testing

OBJECTIVE(continued)• Black-Box Testing• It is also called behavioural testing, focuses on the functional requirements

of the software. It enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.

• Black Box testing is not an alternative to white box testing rather; it is a complementary approach that is likely to uncover a different class of errors than white box methods.

• The various black-box testing techniques are:• Graph-based Testing• Equivalence Partitioning• BV Analysis• Comparison testing• Orthogonal array Testing

TESTING PROCEDURES• There are three testing procedures: -• UNIT TESTING: This is the testing of an individual module and is usually carried out to ensure the validity

of a particular module.• DESIGNING TEST CASES: As a minimal starting point, every line of code must be tested. Thus if any decision

structure are present in your method, you will need to define test cases that include all of the possibilities presented by that structure. The number of test cases needed to run every line of code testing of all possible data paths should be considered the absolute minimum for designing a unit test plan.

• TESTING DATA: Testing the functionality of all possible data point provides a good starting point for test plan. But to make application robust, one must test that it can handle different kind of data. Application must behave normally and give expected results when data within normal parameters is provided, and it should gracefully and appropriately handle data that is outside of the specified bounds. Thus, to be complete, one must test application with a variety of data inputs that are normal and extraordinary.

• NOTE: It makes use of white box testing technique. • INTEGRATED TESTING: Integrated testing is the testing of the system modules. This is done to identify

errors, which relate to the interaction of different module, which cannot be found by unit testing but only through an interactive testing.

• NOTE: It makes use of black box testing technique.• SYSTEM TESTING:-System testing is the testing of the system against its initial objectives. It is done either

in a simulated environment or in a live environment.• VALIDATION TESTING: Validation testing is the testing where requirement established as part of software

requirement analysis are validated against the software that has been constructed.• NOTE: It makes use of black box testing technique.

CONCLUSION