Download Software Engineering and Project Management and more Study notes Interface between Computer Science and Economics in PDF only on Docsity!
UNIT I
INTRODUCTION
Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations.
Software Engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures.
Software Engineering process Paradigms (SDLC)
SDLC: SDLC is a step by step procedure or systematic approach to develop software and it is followed within a software organization. It consists of various phases which describe how to design, develop, enhance and maintain particular software.
Phase 1: Requirement collection and analysis: In this phase mainly focus on gathering the business needs from the customer. Business Analyst collects the requirement from the customer and prepares the BRS (Business Requirement Specification) which has the requirement in the business form. Then a group of people sits together and determines the requirements like; What should be input data to the system? Who is going to use the system?
What should be output data by the system? These questions are getting answered during this phase. After this, a Requirement Specification document is created which gives the guideline for the upcoming phase of the model.
Phase 2: Feasibility study:
Once the BRS document is completed, a set of people like Human Resource department, Finance department, Business analyst, Architect and Project manager are sit together and analyze if the project is do able or not. This decision is taken based on the cost, time, resources and etc.
Phase 3: Design: In this phase system design specification is prepared from the requirement document. Design is a blue print of the application and it helps in specifying hardware and requirements of the system and helps in defining architecture of the system
Phase 4: Coding: Once the system design document is ready, in this phase developer’s starts writing the code using any programming language i.e., they start developing the software. Generally task is divided in units or modules and assigned to the developers and this coding phase is the longest phase of SDLC. Phase 5: Testing: Once the software is ready and is deployed in the testing environment, test engineers starts testing, if the functionality of an application is working according to requirement or not. During this phase test engineers may encounter some bugs/defects which need to be sent to developers, the developers fix the bug and sent back to test engineers for testing. This process continuous until the software is bug free/stable/working according to the requirement. Phase 6: Installation/Deployment: Once the product developed, tested and works according to the requirement it is installed / deployed at customer place for their use. Phase 7: Maintenance: When the customers starts using the software they may face some issues and needs to be solved, to fix those issue, tested and handed over back to the customer as soon as possible, which is done in the maintenance phase.
Waterfall Model
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing. Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures. Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market. Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.
Waterfall Model – Advantages Simple and easy to understand and use Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood. Clearly defined stages. Easy to arrange tasks.
Waterfall Model – Disadvantages No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. It is difficult to measure progress within stages.
Iterative Model:
- Planning Phase: This is the first stage of the iterative model, where proper planning is done by the team, which helps them in mapping out the specifications documents, establish software or hardware requirements and generally prepare for the upcoming stages of the cycle.
- Analysis and Design Phase: Once the planning is complete for the cycle, an analysis is performed to point out the appropriate business logic, database models and to know any other requirements of this particular stage. Moreover, the design stage also occurs in this phase of iterative model, where the technical requirements are established that will be utilized in order to meet the need of analysis stage.
- Implementation Phase : This is the third and the most important phase of the iterative model. Here, the actual implementation and coding process is executed. All planning, specification, and design documents up to this point are coded and implemented into this initial iteration of the project.
- Testing Phase: After the current build iteration is coded and implemented, testing is initiated in the cycle to identify and locate any potential bugs or issues that may have been in the software.
Spiral model is a combination of sequential and prototype model. This model is best used for large projects which involves continuous enhancements. There are specific activities which are done in one iteration (spiral) where the output is a small prototype of the large software. The same activities are then repeated for all the spirals till the entire software is build. A spiral model has 4 phases described below:
- Planning phase
- Risk analysis phase
- Engineering phase
- Evaluation phase. Activities which are performed in the spiral model phases are shown below:
Phase Name
Activities performed Deliverables / Output
Planning - Requirements are studied and gathered.
- Feasibility study
- Reviews and walkthroughs to streamline the requirements
Requirements understanding document
Finalized list of requirements.
Risk Analysis
Requirements are studied and brain storming sessions are done to identify the potential risks
Once the risks are identified , risk mitigation strategy is planned and finalized
Document which highlights all the risk & its mitigation plans.
Engineering Actual development and testing if the software takes place in this phase
Code Test cases and test results Test summary report and defect report.
Evaluation Customers evaluate the software and provide their feedback and approval
Features implemented document
Advantages of using Spiral Model: Development is fast Larger projects / software are created and handled in a strategic way Risk evaluation is proper. More and more features are added in a systematic way. Software is produced early. Disadvantages of using Spiral model: Risk analysis is important phase so requires expert people. Is not beneficial for smaller projects. Spiral may go infinitely. Documentation is more as it has intermediate phases. It is costly for smaller projects.
V-Model
The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape. It is also known as Verification and Validation model. The following illustration depicts the different phases in a V-Model of the SDLC.
Unit Testing
Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.
Integration Testing Integration testing is associated with the architectural design phase.
System Testing System tests check the entire system functionality and the communication of the system under development with external systems.
Acceptance Testing Acceptance tests uncover the compatibility issues with the other systems available in the user environment. The advantages of the V-Model method are as follows − This is a highly-disciplined model and Phases are completed one at a time. Works well for smaller projects where requirements are very well understood. Simple and easy to understand and use. The disadvantages of the V-Model method are as follows − High risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for the projects where requirements are at a moderate to high risk of changing.
Project Management Concepts (Or) Spectrum
- The People
- The Product (or) problem
- The Process
- The Project
The People: The Stakeholders
Four categories of stakeholders
- Senior managers – define business issues that often have significant influence on the project.
- Project (technical) managers – plan, motivate, organize, and control the practitioners who do the work.
- Customers – specify the requirements for the software engineer.
- Users – interact with the software once it is released for production use
The People: Team Leaders
- Team leaders should use a problem-solving management style.
- Concentrate on understanding the problem to be solved
- Manage the flow of ideas.
The People: The Software Team The People: Coordination and Communication Issues
Documents, Milestones, Memos, Review Meetings, Inspections , Information Meetings, Problem Solving ,E- Mail, Bulletin Boards, Video Conferencing ,Discussion With People Outside Project Team
The Product
- The scope of the software development must be established and bounded
- Context – How does the software to be built fit into a larger system? And what constraints are imposed as a result of the context?
- Information objectives – What customer-visible data objects are produced as output from the software? What data objects are required for input?
- Function and performance – What functions does the software perform to transform input data into output? Are there any special performance characteristics to be addressed?
The Process
The project manager must decide which process model is most appropriate based on framework activities.
- Customer communication
- Planning
- Risk analysis
- Indicator.
- These indicators provide a detailed insight into the software process, software project, or intermediate product. Indicators also enable software engineers or project managers to adjust software processes and improve software products, if required. Process and project Indicator Process Indicator Process Indicators are collected across all projects and over long periods of time. Their intent is to provide indicators that lead to long term software process improvement.
Project Indicator Enables a software project manager to
- Assess the status of an ongoing project
- Track potential risks.
- Uncover problem areas before they go “Critical”
- Adjust work flow or tasks
- Evaluate the project team’s ability to control quality of software work products.
Process Metrics and Software Process Improvement
Factors that influence quality:
- people - skills and experience of SW people
- technology - used in development (e.g. CASE)
- product complexity
Types of process metrics:
Private &. public metrics
SW process improvement should begin at the individual level
Private metrics:
defect rates by individual defect rates by module errors found during development
Public metrics: Use information from individual and team metrics Some public metrics: project-level defect rates effort Calendar times Software Measurement Categories in 2 ways: Direct measure of the software process & Product E.g. Lines of code (LOC), execution speed, and defect) Indirect measures of the product that includes functionality, complexity, efficiency, reliability, maintainability etc. Size Oriented Metrics Size - oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced. A set of simple size - oriented metrics can be developed for each project: Errors per KLOC (thousand lines of code). Defects4 per KLOC.
Number of user outputs
Each user output that provides application-oriented information to user (reports, screens, error messages, etc.).
Number of inquiries Inquiry is an on-line input that results in generation of an immediate SW response in form of an on-line output.
Number of internal files Include each logical file or if using a DB, logical grouping of data, that is generated, used and maintained by the application.
Number of external interfaces Files passed or shared between applications should be counted. Compute: the function points calculation FP= count-total * [0.65+.01* Fi ]
Reconciling LOC and FP metric: Relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the design. Following table provides rough estimates of the average number of LOC required to build one FP in various programming languages:
Metrics for SW Quality Focus on the process, the project and the product (as do productivity metrics)
Factors that affect quality
product operation - using it product revision - changing it product transition - portability
Measuring quality:
correctness degree to which SW performs its required function Defects per KLOC - most common measure for correctness. Maintainability. Ease with which a program can be corrected, adapted, or enhanced. MTTC - mean time to change - Simple metric - time it takes to analyze, implement change, test it, and distribute it to users. Integrity
- Measures system’s ability to withstand attacks on its security. Usability
- Quantify user friendliness.
Defect Removal Efficiency(DRE)
- Defect removal efficiency provides benefits at both the project and process level.
- It is a measure of the filtering ability of QA activities as they are applied throughout all process framework activities. - It indicates the percentage of software errors found before software release.
- It is defined as DRE = E / (E + D).
- E is the number of errors found before delivery of the software to the end user. -- D is the number of defects found after delivery.
SOFTWARE PROJECT ESTIMATION
Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on −
E represents effort, in person months,
S is the size of the software development, in LOC or FP, and,
a, b, and c are values derived from data
COCOMO: When Barry Boehm wrote 'Software Engineering Economics', published in 1981, he introduced an empirical effort estimation model (COCOMO - COnstructive COst MOdel) that is still referenced by the software engineering community. The model has been reviewed since 1981 and details of the revised and updated COCOMO 2 model.
The original COCOMO model was a set of models; 3 development modes (organic, semi-detached, and embedded) and 3 levels (basic, intermediate, and advanced). COCOMO model levels:
Basic - predicted software size (lines of code) was used to estimate development effort.
Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost drivers' was used to estimate development effort
Advanced - on top of the intermediate model, the advanced model allows phase-based cost driver adjustments and some adjustments at the module, component, and system level.
COCOMO development models: Organic - small relatively small, simple software projects in which small teams with good application experience work to a set of flexible requirements.
Embedded - the software project has tight software, hardware and operational constraints. Semi-detached – an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.
Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the three model i.e., organic, semi-detached & embedded.
Solution: The basic COCOMO equation takes the form:
Effort=a 1 *(KLOC) a 2 PM Tdev=b 1 *(efforts)b 2 Months Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode E = 3.0 * (400)1.12=2462.79 PM D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM D = 2.5 * (4772.8)0.32 = 38 PM
Project Planning
The project plan sets out the resources available about to the project, the work breakdown and a schedule for carrying out the work. Most plans should include the following sections:
- Introduction: This briefly describes the objectives of the project and sets out the constraints (Eg: budget, time etc) which affect the project management.
- Project Organisation: This describes the way in which the development team is organized, the people involved and their roles in the team.
- Risk analysis: This describes possible project risks, the likelihood of these risks arising and the risk reduction strategies, which are proposed.
- Hardware and Software resource Requirements : This describes the hardware and the support software required to carry out the development.
- Work Breakdown : This describes the breakdown of the project into activities and identifies the milestones ans deliverables associated with each activity.
- Project Schedule: This describes the dependencies between activities , the estimated time required to reach each milestone and the allocation of people to the activities.
- Monitoring and reporting mechanism : This describes the management reports which should be produced , when these should be produced and the project monitoring mechanisms used.
