Post on 16-Jan-2016
description
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