Development Environment An integrated development environment IDE is

Development Environment • An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. • An IDE normally consists of a source code editor, build automation tools and a debugger. Ajith G. S: poposir. orgfree. com

Development Refactoring Tools • The term refactoring is “rearranging code to make it easier to understand, more maintainable, or generally better. ” • Some refactoring tools let to do things like easily define new classes or methods. • Refactoring tools can be particularly useful if managing existing code Ajith G. S: poposir. orgfree. com

Development Testing Tools • Testing tools, particularly automated tools, can make testing a whole lot faster, easier, and more reliable Ajith G. S: poposir. orgfree. com

Testing • Testing is an activity to check whether the actual results match the expected results and to ensure that the software system is Defect free. • It involves execution of a software component or system component to evaluate one or more properties of interest. • Testing helps to identify errors, gaps or missing requirements in contrary to the actual requirements. • It can be either done manually or using automated tools. • Two types : ‐ White Box and Black Box Testing. Ajith G. S: poposir. orgfree. com

Deployment • Deployment is the process of putting the finished application in the users’ hands • Scope • A project’s scope can range from a small tool you wrote for your own use, to in‐house business software that will be used by hundreds or thousands of users • If you write an application for your own use and it doesn’t work, you’ve only inconvenienced yourself and you have no one else to blame. • If you roll out a new version of an operating system to millions of customers and then immediately discover you need to send out a security fix, you lose credibility. Ajith G. S: poposir. orgfree. com

Deployment • The Plan • To start deployment planning, list the steps that hope to follow. • Describe each step in detail as it is supposed to work. • Cutover is the process of moving users to the new application. • There are several ways you can manage cutover Ajith G. S: poposir. orgfree. com

Deployment • Cutover • 1) Staged Deployment • In staged deployment , build a staging area , a fully functional environment where you can practice deployment. • 2) Gradual Cutover • In gradual cutover , install the new application for some users while other users continue working with their existing system. Ajith G. S: poposir. orgfree. com

Deployment • Incremental Deployment • In incremental deployment , release the new system’s features to the users gradually. • First, install one tool (possibly using staged deployment or gradual cutover to ease the pain). • After the users are used to the new tool, you give them the next tool. Ajith G. S: poposir. orgfree. com

Software Maintainability • Maintainability is a qualitative indication of the ease with which existing software can be corrected, adapted, or enhanced. • Maintainable software exhibits effective modularity • It makes use of design patterns that allow ease of understanding. • It has been constructed using well‐defined coding standards and conventions, leading to source code that is self‐ documenting and understandable Ajith G. S: poposir. orgfree. com

Software Maintainability • It has undergone a variety of quality assurance techniques that have uncovered potential maintenance problems before the software is released. • It has been created by software engineers who recognize that they may not be around when changes must be made. • Therefore, the design and implementation of the software must “assist” the person who is making the change. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Objective • The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Software scope • Software scope describes the functions and features that are to be delivered to end users; • The data that are input and output; • The “content” that is presented to users as a consequence of using the software; and • The performance, constraints, interfaces, and reliability that bound the system. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Software scope • Scope is defined using one of two techniques: • 1. A narrative description of software scope is developed after communication with all stakeholders. • 2. A set of use cases is developed by end users • Performance considerations encompass processing and response time requirements. • Constraints identify limits placed on the software by external hardware, available memory, or other existing systems. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Software scope • Once scope has been identified (with the concurrence of the customer), it is reasonable to ask: • “Can we build software to meet this scope? • Is the project feasible? ” Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources • The second planning task is estimation of the resources required to accomplish the software development. • Resources are the people, reusable software components, and the development environment (hardware and software tools). • Each resource is specified with four characteristics: • Description of the resource, • A statement of availability, • Time when the resource will be required • Duration of time that the resource will be applied. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources • Human Resources • The planner begins by evaluating software scope and selecting the skills required to complete development. • For relatively small projects (a few person‐months), a single individual may perform all software engineering tasks, consulting with specialists as required. • For larger projects, the software team may be geographically dispersed across a number of different locations. • The number of people required for a software project can be determined only after an estimate of development effort (e. g. , person‐months) is made. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources : ‐ Reusable Software Resources • Off‐the‐shelf components. • Existing software that can be acquired from a third party or from a past project. • COTS (commercial off‐the‐shelf) components are purchased from a third party, are ready for use on the current project, and have been fully validated. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources : ‐ Reusable Software Resources • Full‐experience components. • Existing specifications, designs, code, or test data • developed for past projects that are similar to the software to be built for the current project. • Members of the current software team have had full experience in the application area represented by these components. • Therefore, modifications required for full‐experience components will be relatively low risk. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources : ‐ Reusable Software Resources • Partial‐experience components. • Existing specifications, designs, code, or test data • developed for past projects that are related to the software to be built for the current project but will require substantial modification. • Members of the current software team have only limited experience in the application area represented by these components. • Therefore, modifications required for partial‐experience components have a fair degree of risk • New components. Software components must be built by the software team specifically for the needs of the current project. Ajith G. S: poposir. orgfree. com

Project Planning : ‐ Resources : ‐ Environmental Resources • The environment that supports a software project, often called the software engineering environment (SEE), incorporates hardware and software. • Hardware provides a platform that supports the tools (software) required to produce the work products • that are an outcome of good software engineering practice. Ajith G. S: poposir. orgfree. com

Empirical Estimation Model • The empirical data that support most estimation models are derived from a limited sample of projects. • Software cost and effort estimation will never be an exact science. • Too many variables—human, technical, environmental, political— can affect the ultimate cost of software and effort applied to develop it. • A model is based on experience (historical data) and takes the form • d= f (vi) • where d is one of a number of estimated values (e. g. , effort, cost, project duration) and vi are selected independent parameters (e. g. , estimated LOC or FP). Ajith G. S: poposir. orgfree. com

The COCOMO II Model • Barry Boehm introduced software estimation models called COCOMO, for COnstructive COst MOdel. • Like all estimation models for software, the COCOMO II models require sizing information. • Three different sizing options are available as part of the model hierarchy: object points, function points, and lines of source code. Ajith G. S: poposir. orgfree. com

The COCOMO II Model • The COCOMO II application composition model uses object points Ajith G. S: poposir. orgfree. com

The COCOMO II Model • Like function points, the object point is an indirect software measure that is computed using counts of the number of • (1) screens (at the user interface), • (2) reports, • (3) components likely to be required to build the application. • Each object instance (e. g. , a screen or report) is classified into one of three complexity levels (i. e. , • simple, medium, or difficult) using criteria suggested by Boehm [Boe 96]. • Complexity is a function of the number and source of the client and server data tables that are required to generate the screen or report and the number of views or sections presented as part of the screen or report. Ajith G. S: poposir. orgfree. com

The COCOMO II Model • Once complexity is determined, the number of screens, reports, and components are weighted according to the table. • The object point count is then determined by multiplying the original number of object instances by the weighting factor in the figure and summing to obtain a total object point count. Ajith G. S: poposir. orgfree. com

The COCOMO II Model • When component‐based development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated and the object point count is adjusted: • NOP= (object points) * [(100 ‐ %reuse)/100]. • where NOP is defined as new object points • To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be derived. Figure 26. 7 presents the productivity rate. • PROD=NOP/Person‐Month • for different levels of developer experience and development environment maturity Ajith G. S: poposir. orgfree. com

The COCOMO II Model • Once the productivity rate has been determined, an estimate of project effort is computed using • Estimated effort =NOP/PROD Ajith G. S: poposir. orgfree. com

The COCOMO II Model • Productivity rate for object points. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Personnel Planning deals with staffing. • Staffing deals with the appoint personnel for the position that is identified by the organizational structure. • It involves: • • Defining requirement for personnel Recruiting (identifying, interviewing, and selecting candidates) Compensating Developing and promoting agent • For personnel planning and scheduling, it is helpful to have efforts and schedule size for the subsystems and necessary component in the system. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • At planning time, when the system method has not been completed, the planner can only think to know about the large subsystems in the system and possibly the major modules in these subsystems. • Once the project plan is estimated, and the effort and schedule of various phases and functions are known, staff requirements can be achieved. • From the cost and overall duration of the projects, the average staff size for the projects can be determined by dividing the total efforts (in person‐months) by the whole project duration (in months). Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Typically the staff required for the project is small during requirement and design, the maximum during implementation and testing, and drops again during the last stage of integration and testing. • Using the COCOMO model, average staff requirement for various phases can be calculated as the effort and schedule for each method are known. • When the schedule and average staff level for every action are well‐known, the overall personnel allocation for the project can be planned. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • This plan will indicate how many people will be required for different activities at different times for the duration of the project. • The total effort for each month and the total effort for each step can easily be calculated from this plan. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Team Structure • Team structure addresses the issue of arrangement of the individual project teams. There are some possible methods in which the different project teams can be organized. There are primarily three formal team structures: chief programmer, Ego‐ less or democratic, and the mixed team organizations even several other variations to these structures are possible. Problems of various complexities and sizes often need different team structures for the chief solution. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Ego‐Less or Democratic Teams • Ego‐Less teams subsist of a team of fewer programmers. The objective of the group is set by consensus, and input from each member is taken for significant decisions. Group leadership revolves among the group members. Due to its nature, egoless teams are consistently known as democratic teams. • The structure allows input from all representatives, which can lead to better decisions in various problems. This suggests that this method is well suited for long‐term research‐type projects that do not have time constraints. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • • Chief Programmer Team A chief‐programmer team, in contrast to the ego‐less team, has a hierarchy. It consists of a chief‐programmer, who has a backup programmer, a program librarian, and some programmers. The chief programmer is essential for all major technical decisions of the project. He does most of the designs, and he assigns coding of the different part of the design to the programmers. The backup programmer uses the chief programmer makes technical decisions, and takes over the chief programmer if the chief programmer drops sick or leaves. The program librarian is vital for maintaining the documentation and other communication‐related work. This structure considerably reduces interpersonal communication. The communication paths, as shown in fig: Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Once Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • • • Controlled Decentralized Team • It consists of project leaders who have a class of senior programmers under him, while under every senior programmer is a group of a junior programmer. • The group of a senior programmer and his junior programmers behave like an ego‐less team, but communication among different groups occurs only through the senior programmers of the group. • The senior programmer also communicates with the project leader. • Such a team has fewer communication paths than a democratic team but more paths compared to a chief programmer team. • This structure works best for large projects that are reasonably straightforward. It is not well suited for simple projects or research‐ type projects. (Hierarchical Team Structure) A third team structure known as the controlled decentralized team tries to combine the strength of the democratic and chief programmer teams. Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning Ajith G. S: poposir. orgfree. com

Staffing and Personal Planning • Once Ajith G. S: poposir. orgfree. com