UNIT I - SOFTWARE PROCESS AND PROJECT MANAGEMENT Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models Software Project Management: Estimation LOC and FP Based Estimation, COCOMO Model Project Scheduling Scheduling, Earned Value Analysis - Risk Management. Introduction: What is software? Computer programs and associated documentation is software. Software products may be developed for a particular customer or may be developed for a general market. Software products may be Generic - developed to be sold to a range of different customers. Bespoke (custom) - developed for a single customer according to their specification. What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production. Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. What is the difference between software engineering and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. Computer science theories are currently insufficient to act as a complete underpinning for software engineering. What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process. System engineers are involved in system specification, architectural design, integration and deployment. What is a software process? A set of activities whose goal is the development or evolution of software is a software process. Generic activities in all software processes are: Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing Demands Department of Information Technology/SVCE Page 1
What is a software process model? A simplified representation of a software process, presented from a specific perspective Examples of process perspectives are Workflow perspective - sequence of activities Data-flow perspective - information flow Role/action perspective - who does what Generic process models are: Waterfall Evolutionary development Formal transformation Integration from reusable components What are the costs of software engineering? Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability. Distribution of costs depends on the development model that is used What are software engineering methods? Structured approaches to software development which include system models, notations, rules, design advice and process guidance. Model descriptions Descriptions of graphical models which should be produced Rules Constraints applied to system models Recommendations Advice on good design practice Process guidance What activities to follow What is CASE (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support Upper-CASE Tools to support the early process activities of requirements and design Lower-CASE Tools to support later activities such as programming, debugging and testing Department of Information Technology/SVCE Page 2
What are the attributes of good software? The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. Maintainability Software must evolve to meet changing needs Dependability Software must be trustworthy Efficiency Software should not make wasteful use of system resources Usability Software must be usable by the users for which it was designed What are the key challenges facing software engineering? Coping with legacy systems, coping with increasing diversity and coping with demands for reduced delivery times. Legacy systems Old, valuable systems must be maintained and updated Heterogeneity Systems are distributed and include a mix of hardware and software Delivery There is increasing pressure for faster delivery of software Professional and ethical responsibility Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law. Issues of professional responsibility Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence. Intellectual property rights Department of Information Technology/SVCE Page 3
Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse Software engineers should not use their technical skills to misuse other people s computers. Computer misuse ranges from relatively trivial (game playing on an employer s machine, say) to extremely serious (dissemination of viruses). Code of ethics - preamble Preamble The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles: Code of ethics - principles 1. PUBLIC Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. JUDGMENT Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION Department of Information Technology/SVCE Page 4
Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES Software engineers shall be fair to and supportive of their colleagues. 8. SELF Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. Ethical dilemmas Disagreement in principle with the policies of senior management. Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. Participation in the development of military weapons systems or nuclear systems. The Software Process: A structured set of activities required to develop a software system Specification Design Validation Evolution A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Software Process Models Generic software process models The waterfall model Separate and distinct phases of specification and development Evolutionary development Specification and development are interleaved Formal systems development A mathematical system model is formally transformed to an implementation Reuse-based development The system is assembled from existing components. Department of Information Technology/SVCE Page 5
Waterfall model phases Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the difficulty of accommodating change after the process is underway. Waterfall model problems Inflexible partitioning of the project into distinct stages. This makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood. Evolutionary development Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements. Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements. Department of Information Technology/SVCE Page 6
Problems Lack of process visibility Systems are often poorly structured Special skills (e.g. in languages for rapid prototyping) may be required Applicability For small or medium-size interactive systems For parts of large systems (e.g. the user interface) For short-lifetime systems. Formal systems development Based on the transformation of a mathematical specification through different representations to an executable program Transformations are correctness-preserving so it is straightforward to show that the program conforms to its specification. Embodied in the Cleanroom approach to software development. Department of Information Technology/SVCE Page 7
Formal systems development Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Applicability Critical systems especially those where a safety or security case must be made before the system is put into operation. Reuse-oriented development Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages Component analysis Department of Information Technology/SVCE Page 8
Requirements modification System design with reuse Development and integration This approach is becoming more important but still limited experience with it. Process iteration System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models. Two (related) approaches Incremental development Spiral development. Incremental development Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early Increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Department of Information Technology/SVCE Page 9
Incremental development advantages Customer value can be delivered with each increment so system functionality is available Earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. Extreme programming New approach to development based on the development and delivery of very small increments of functionality. Relies on constant code improvement, user involvement in the development team and pairwise programming. Spiral development Process is represented as a spiral rather than as a sequence of activities with backtracking Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. Department of Information Technology/SVCE Page 10
Spiral model sectors Objective setting Specific objectives for the phase are identified Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks Development and validation A development model for the system is chosen which can be any of the generic models Planning The project is reviewed and the next phase of the spiral is Planned. Software specification The process of establishing what services are required and the constraints on the system s operation and development Requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Department of Information Technology/SVCE Page 11
Software Project Management Project Management Poor managment is the downfall of many software projects Delivered software was late, unreliable, cost several times the original estimates and often exhibited poor performance characteristics. Software project management is different from other engineeering management. product is intangible still no clear understanding of the software process or evaluation criteria most software projects are new and technically innovative Good management cannot guarantee project success, but bad management usually results in project failure! Management Activities Proposal writing overview, estimates, justification Project costing software cost estimation Project planning and scheduling milestones, options to m inimize risks Project monitoring and reviewing progress, compare to schedule and planned costs, predict problems Personnel selection and evaluation skill, experience, training, resources Report writing and presentation primary summary documentation and progress reviews. Statements about Management Software project management is an essential part of software engineering. Without proper planning, a software development project is doomed. Good management cannot guarantee project success. However, bad management usually result in project failure: The software is delivered late, costs more than originally estimated, and fails to its requirement. Project Organizations perform works: operations and projects Commonalities between operations and projects Performed by people Constrained by the limited resources Planned, executed, and controlled Differences between operations and projects Operations are on going and repetitive Projects are temporary and unique. Note:Software project management is especially difficult because. Department of Information Technology/SVCE Page 12
IEEE Guide Adoption of PMI Standard A Guide to the Project Management Body of Knowledge IEEE Std 1490 1998 IEEE Standard for Software Project Management Plans IEEE Std 1058 1998 Software project management : The Manager s View. Metrics Numerical measures that quantify the degree to which software, a process or a project possesses a given attribute Metrics help the followings Determining software quality level Estimating project schedules Tracking schedule process Determining software size and complexity Determining project cost Process improvement. Software Metrics Without measure it is impossible to make a plan, detect problems, and improve a process and product. A software engineer collects measure and develops metrics so that indicators will be obtained. An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the product to make things better. The five essential, fundamental metrics: Size (LOC, etc.) Department of Information Technology/SVCE Page 13
Cost (in dollars) Duration (in months) Effort (in person month) Quality (number of faults detected). Product Size Metrics Conventional metrics Size oriented metrics Function oriented metrics Empirical estimation models Object Oriented metrics Number of scenario scripts Number of key classes Number of support classes Average number of support classes per key classes User Case oriented metrics. Web engineering product metrics Number of static web pages Number of dynamic web pages Number of internal page links Number of persistent page links. Size Estimation The methods to achieve reliable size and cost estimates: LOC based estimation FP based estimation Empirical estimation models COCOMO Department of Information Technology/SVCE Page 14
LOC based Estimation The problems of lines of code (LOC) Different languages lead to different lengths of code It is not clear how to count lines of code A report, screen, or GUI generator can generate thousands of lines of code in minutes Depending on the application, the complexity of code is different. Department of Information Technology/SVCE Page 15
FP based Estimation Based on FP metric for the size of a product Based on the number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf) Step 1: Classify each component of the product (Inp, Out, Inq, Maf, Inf) as simple, average, or complex (Figure 1) Assign the appropriate number of function points The sum of function pointers for each component gives UFP (unadjusted function points). Step 2: Compute the technical complexity factor (TCF) Assign a value from 0 ( not present ) to 5 ( strong influence throughout ) to each of 14 factors such as transaction rates, portability (Figure 2) Add the 14 numbers: This gives the total degree of influence (DI) TCF = 0.65 + 0.01 DI The technical complexity factor (TCF) lies between 0.65 and 1.35 Step 3.The number of function points (FP) is then given by FP = UFP TCF. Department of Information Technology/SVCE Page 16
Exercise Problems A target product has 7 simple inputs, 2 average input, and 10 complex inputs. There are 56 average output, 8 simple inquires, 12 average master files, and 17 complex interfaces. Determine the unadjusted function points (UFP). If the total degree of influence for the product of the question above is 49, determine the number of function points. Department of Information Technology/SVCE Page 17
COCOMO COnstructive COst MOdel Empirical model Metrics such as LOC and FP are used as input to a model for determining product cost and duration Well documented, and supported by public domain and commercial tools; Widely used and evaluated Has a long pedigree from its first instantiation in 1981 COCOMO I (81) COCOMO II Based on water fall process model The vast majority of software would be developed from the scratch There are three forms of the COCOMO Basic COCOMO (macro estimation) which gives an initial rough estimate of man months and development time Intermediate COCOMO which gives a more detailed estimate for small to medium sized projects Detailed COCOMO (micro estimation) which gives a more detailed estimate for large projects. Effort = A * SizeB * M Where A is coefficient The exponent B reflects the increased effort required as the size of the product increases The multiplier M is based on the project Characteristics. Department of Information Technology/SVCE Page 18
Step 1. Estimate the length of the product in KLOC Step 2. Estimate the product development mode Simple (organic, straightforward) Moderate (medium sized, semidetached) Complex (embedded) Step 3. Compute the nominal effort Step 4. Multiply the nominal value by 15 software development cost multipliers Step 5. Estimate the calendar time (TDEV) in months required to complete a project. Intermediate COCOMO Example Example: Microprocessor based communications processing software for electronic funds transfer network. Step 1. Estimate the length of the product 10,000 LOC (10 KLOC) Step 2. Estimate the product development mode Complex ( embedded ) mode Step 3. Compute the nominal effort Nominal effort = 2.8 * (10)1.20 = 44 man months. Step 4. Multiply the nominal value by 15 software development cost multipliers (see table on the next slide) Product of effort multipliers = 1.35 Estimated effort for project is therefore 1.35 * 44 = 59 person (man) months. Department of Information Technology/SVCE Page 19
Results of the Intermediate COCOMO COCOMO has been validated with respect to broad samples (63) COCOMO was the most accurate estimation method of its time Major problem If the estimate of the number of lines of codes of the target product is incorrect, then everything is incorrect. COCOMO II 1995 extension to 1981 COCOMO that incorporates Object orientation, Modern life cycle models, Rapid prototyping, Fourth generation languages, COTS software. COCOMO II is far more complex than the first version. Exercise Problem You are in charge of developing a 76 KLOC embedded product that is nominal except that the database size is rated very high and the use of software tools is low. Using Intermediate COCOMO, what is the estimated effort in person (man) months? Project Planning and Scheduling Project planning determines a project schedule based upon project constraints (delivery, staff, budget) project parameters (structure, size, functions) project milestones and deliverables Planning and scheduling must estimate risk associated with each decision. Project scheduling involves separating work into tasks and predicting task completion coordinate parallel tasks to optimize work force allow for problems Schedule must be periodically revised with progress. Types of Plans o Quality plan Describes the quality procedures and standards that will be used in the project o Validation plan Describes the approach, resources and schedule used for system validation o Configuration management plan Describes the configuration management procedures and strcutures to be used o Maintenance plan Predicts the maintenance requirements of the system, maintenance cost and effort required o Staff development plan Describes how the skills and experience of the project team members will be developed The Project Plan o Introduction Briefly describes the objectives of the product and sets out the constraints (budget, time, etc.) o Project Organization Describes the way in which the development team is organized o Risk analysis Describes possible project risks and risk reduction strategies Department of Information Technology/SVCE Page 20
o Hardware & Software resource requirements Hardware/Software required to carry out the development o Work breakdown Breakdown of the project into activities, identification of milestones and deliverables o Project schedule Describes the dependencies between activities, the estimated time required to reach each milestone and the allocation of people to activites o Monitoring and reporting techniques Describes the management reports which should be produced Department of Information Technology/SVCE Page 21
Department of Information Technology/SVCE Page 22
Factors affecting Software Pricing o Market opportunity Moving into new markets --> low pricing. o Cost estimation uncertainty If organization is unsure of its cost estimate, it may increase its price o Contractual terms. Customer may be w illing to allow the developer to retain ownership of the source code and reuse it in other projects. o Requirements volatility If requirements are likely to change offer low er price to win the contract. After contract has been awarded, high prices may be charged for changes to the requirements o Financial health. Sometimes it may be better to make a small profit or break even than to go out of business. Risk Management o An engineering project is expected to produce a reliable product within a limited time using limited resources o Risk management identifying project risks assessing their im pact monitoring and controlling the risks Department of Information Technology/SVCE Page 23
o Approaches to reduce risks in Software Engineering Prototyping Incremental delivery Modular design (i.e. handling risks of late changes) Department of Information Technology/SVCE Page 24