vnd.openxmlformats-officedocument.presentationml.presentation&rendition=1.pptx
- 1. UNIT II Software Project Management Renaissance 1
- 2. 1. Make quality #1. 2. High-quality software is possible. 3. Give products to customers early. 4. Determine the problem before writing the requirements. 5. Evaluate design alternatives. 6. Use an appropriate process model. 7. Use different languages for different phases. 8. Minimize intellectual distance. 9. Put techniques before tools. 10. Get it right before you make it faster. 11. Inspect code. 12. Good management is more important than good technology. THE PRINCIPLES OF CONVESIONAL SOFTWARE ENGINEERING 2
- 4. 🞭 System requirements :- over all requirements, hardware specifications, environment etc 🞭 Software requirements :- functional requirements 🞭 Analysis :- check whether it is feasible 🞭 Design :- valid design which should be developed 🞭 Coding :- development and monitoring 🞭 Testing :- checking whether the software meets the requirements or not 🞭 Operations :- includes implementation and maintenance 4
- 5. SOFTWARE ECONOMICS 🞭 SOFTWARE ECONOMICS can be abstracted into a function of five basic parameters: 🞭 size, process, personnel, environment, and required quality 1.The sizeof the end product (quantified in number of source instructions or function points) 2.The processused to produce the end product 3.The capabilities of software engineering personnel 4.The environment,which is made up of the tools and techniques 5.The required qualityof the product (its features, performance, reliability, and adaptability) 🞭 The relationships among these parameters and the estimated cost can be written as follows: Effort= (Personnel)(Environment)(Quality)(SizeProcess) CONVENSTIONAL SOFTWARE MANAGEMENT PERFORMANCE 5
- 6. PRAGMA TIC SOFTWARE COST ESTIMA TION 6 🞭 Pragmatic (practical, realistic, sensible) 🞭 Acritical problem in software cost estimation is a lack of well- documented case 🞭 Some popular cost estimation model : COCOMO, CHECKPOINT, ESTIMACS 🞭 debates on software cost estimation models and tools: 1. Which cost estimation model to use 2.Whether to measure software size in source lines of code or function points 3. What constitutes a good estimate
- 7. IMPROVING SOFTWARE ECONOMICS 7 🞭 Reducing the size or complexity of what needs to be developed. 🞭 Improving the development process. 🞭 Using more-skilled personnel and better teams (not necessarily the same thing). 🞭 Using better environments (tools to automate the process). 🞭 Trading off or backing off on quality.
- 8. THE PRINCIPLES OF MODERN SOFTWARE MANAGEMENT 8 🞭 Base the process on an architecture-first approach. 🞭 Establish an iterative life-cycle process that confronts risk early. component-based 🞭 Transition design methods to emphasize development. 🞭 Establish a change management environment. 🞭 Enhance change freedom through tools that support round-trip engineering. 🞭 Capture design artifacts in rigorous, model-based notation. 🞭 Instrument the process for objective quality control and progress assessment. 🞭 Use a demonstration-based approach to assess intermediate artifacts. 🞭 Plan intermediate releases in groups of usage scenarios with evolving levels of detail. 🞭 Establish a configurable process that is economically scalable.
- 9. DIFFERENCES BETWEEN THE OLD WAY AND NEW WAY 9
- 10. LIFE CYCLE PHASES 10 1. INCEPTION PHASE 2. ELABORATION PHASE 3. CONSTRUCTION PHASE 4. TRANSITION PHASE
- 11. INCEPTION PHASE 11 🞭 The overriding goal is to achieve agreement among stakeholders on the life-cycle objectives for the project. 🞭 Firstphase 🞭 Ad-hoc 🞭 formalities 🞭 Establishing the project's software scope 🞭 Estimating the cost for the entire project 🞭 Estimating the schedule for the entire project 🞭 Estimating potential risks
- 12. ELABORATION PHASE 12 🞭 Considered as the most critical of the four phases 🞭 At the end of this phase, the "engineering" is considered complete 🞭 ensures that the architecture, requirements, and plans are stable enough 🞭 the risks sufficiently reduced 🞭 the cost and schedule for the completion of the development can be predicted within an acceptable range. 🞭 executable architecture prototypeis built 🞭 Minimizing developmentcosts by optimizing resources 🞭 Achieving adequate qualityas rapidlyas practical 🞭 Resource management, control, and process optimization
- 13. CONSTRUCTION PHASE 13 🞭 Represents a production process 🞭 Emphasis is placed on managing resources and controlling operations 🞭 Minimizing development costs by optimizing resources 🞭 Achieving adequate quality as rapidlyas practical 🞭 Resource management, control and process optimization
- 14. TRANSITION PHASE 14 🞭 When project is to be deployed in the end user domain 🞭 This phase could include any of the following activities: 1. Beta testing to validate the new system against user expectations 2. testing and parallel operation relative to a legacy system it is replacing 3. Conversion of operational databases 4. Training of users and maintainers
- 15. ARTIFACT SETS
- 16. THE MANAGEMENT SET Management set artifacts are evaluated, assessed, and measured through a combination of the following: 1. Relevant stakeholder review 2. Analysis of changes between the current version of the artifact and previous versions 3. Major milestone demonstrations of the balance among all artifacts and, in particular, the accuracy of the business case and vision artifacts
- 17. THE ENGINEERING SETS The engineering sets consist of the requirements set, the design set, the implementation set, and the deployment set. Requirements artifacts are evaluated, assessed, and measured through a combination of the following: 1. Analysis of consistency with the release specifications of the management set 2. Analysis of consistency between the vision and the requirements models 3. Mapping against the design, implementation, and deployment sets to evaluate the consistency and completeness and the semantic balance between information in the different sets 4. Analysis of changes between the current version of requirements artifacts and previous versions (scrap, rework, and defect elimination trends) 5. Subjective review of other dimensions of quality
- 18. DESIGN SET The design set is evaluated, assessed, and measured through a combination of the following: 1. Analysis of the internal consistency and quality of the design model 2. Analysis of consistency with the requirements models 3. Translation into implementation and deployment sets and notations (for example, traceability, source code generation, compilation, linking) to evaluate the consistency and completeness and the semantic balance between information in the sets 4. Analysis of changes between the current version of the design model and previous versions (scrap, rework, and defect elimination trends) 5. Subjective review of other dimensions of quality
- 19. REQUIREMENT SET Requirements artifacts are evaluated, assessed, and measured through a combination of the following: 1. Analysis of consistency with the release specifications of the management set 2. Analysis of consistency between the vision and the requirements models 3. Mapping against the design, implementation, and deployment sets to evaluate the consistency and completeness and the semantic balance between information in the different sets 4. Analysis of changes between the current version of requirements artifacts and previous versions (scrap, rework, and defect elimination trends) 5. Subjective review of other dimensions of quality
- 20. MODEL BASED SOFTWARE ARCHITECTURES 20
- 21. MANAGEMENT PERSPECTIVE 21 🞭 Describes the project from managements perspective 🞭 From a management perspective, there are three different aspects of an architecture: 🞭 An architecture (design concept) 🞭 An architecture baseline 🞭 An architecture description TECHNICAL PERSPECTIVE 🞭 Software architecture encompasses the structure of software systems 🞭 It displays the selection of elements and the composition of elements into progressively larger subsystems 🞭 their behavior (collaborations among elements)