software engineering

608 views

Published on

by ashish shrivastav
pune

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
608
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

software engineering

  1. 1. 1 Unit 1 What is Software ? 1. Instructions(computer programs) that when executed provide desired function and performance, 2. Data structures that enable the programs to adequately manipulate information and 3. Documents that describe the operation and use of the programs. Software is a set of utility programs which are input and stored permanently in the computer system . What are the characteristic of Software : 1. Software is developed or engineered, it is not manufactured in the classical sense. 2. Software doesn't “ware out” 3. Most software is custom-built, rather than being assembled from existing components 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  “A systematic approach to the analysis, design, implementation and maintenance of software.”  “ The systematic application of tools and techniques in the development of computer-based applications.”  “ Software Engineering is about designing and developing high-quality software.” Difference between software engineering and software programming Software programming -Single developer -“Toy” applications -Short lifespan -Single or few stakeholders Architect = Developer = Manager = Tester = Customer = User -One-of-a-kind systems -Built from scratch -Minimal maintenance Software engineering -Teams of developers with multiple roles -Complex systems -Indefinite lifespan -Numerous stakeholders
  2. 2. 2 Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User -System families -Reuse to amortize costs -Maintenance accounts for 60%-80% of overall development costs Feasibility study Feasibility Study :An important outcome of the preliminary investigation is the determination that the system requested is feasible . There are three aspects in the feasibility study portion of the preliminary investigation : 1. Technical Feasibility 2. Economic Feasibility 3. Operating Feasibility Technical Feasibility : Can the work of the project be done with current equipment , existing software technology , and available personnel ? If new technology is required , what is the likelihood that it can be developed? Economic Feasibility :Are there sufficient benefits in creating the system to make the cost acceptable ? Or , are the costs of not creating the system so great that the project must be undertaken ? Operational Feasibility :Will the system be used if it is developed and implemented ? Will there be resistance from users that will undermine the possible application benefits.
  3. 3. 3 software development life cycle Waterfall Prototyping Spiral Rapid Application Development model Waterfall Model     Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing. Test – check if all code modules work together and if the system as a whole behaves as per the specifications.  Installation – deployment of system, user-training.  Maintenance – bug fixes, added functionality (an on-going process). Waterfall Strengths  Easy to understand, easy to use  Provides structure to inexperienced staff  Milestones are well understood  Sets requirements stability  Good for management control (plan, staff, track) Prototyping Model  Developers build a prototype during the requirements phase  Prototype is evaluated by end users  Users give corrective feedback  Developers further refine the prototype  When the user is satisfied, the prototype code is brought up to the standards needed for a final product. Steps in prototyping : 1. Identify the user’s known information requirements and features needed in the system. 2. Develop a working prototype. 3. Use the prototype , noting needed enhancements and changes.These expand the list of known system requirements. 4. Revise the prototype based in information gained through user experience. 5. Repeat these steps as needed to achieve a satisfactory system.
  4. 4. 4 When both user and analyst decide that sufficient information has been collected from the prototyping process, they determine how to meet the requirements they have identified. Usually one of the following four alternatives is selected : 1. The prototype is redeveloped . This alternative may mean complete reprogramming from scratch. 2. The prototype is implemented as the complete system. Performance efficiency and methods for user interaction may be sufficient to allow the system to be used as is. 3. The project is abandoned . In this case the prototype has provided enough information to show that a system cannot be developed to meet the desired objectives within existing technology or economic or operational guidelines. 4. Another prototyping series begun.The information gained through the current experience may suggest an entirely different approach to contrasting features. Each alternative is viewed as a successful result of prototyping. The Spiral Model : The spiral model is a software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model .It provides the potential for rapid development of incremental versions of the software .In the spiral model , software is developed in a series of incremental releases .During early iterations , the incremental release might be a paper model or prototype. During later iterations , increasingly more complete versions of the engineered versions are produced.       Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, man-power, experience etc. Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, etc.) Resolve risks
  5. 5. 5 The spiral model is divided into a number of framework activities , also called task regions . • Customer communications – tasks required to establish effective communications between developer and customer. • Planning –tasks required to define resources , timeliness and other project related information. • Risk analysis –tasks required to access both technical and management risks. • Engineering – tasks required to build one or more representations of the application. • Construction and release – tasks required to construct , test , install and provide use support. • Customer evaluation – tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage. The RAD Model : Rapid Action Development is a linear sequential software development process model that emphasizes an extremely short development cycle. If requirements are well understood and project scope is constrained the RAD process enables a development team to create a “fully functional system” within very short time periods . The RAD approach encompasses the following phases : • Business Modeling : The information flow among business functions is modeled in a way that answers the following questions . What drives the business process ? What information is generated ? Where does the information go ? Who processes it ? • Data modeling :The information flow defined as part of business modeling phase is refined into a set of data objects that are needed to support the business . The characteristics (called attributes) of each object are identified and the relationships between these objects are defined . • Process modeling : The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. • Application generation :The RAD process works to reuse existing program components(when possible) to create reusable components (when necessary). Automated tools are used to facilitate construction of software. • Testing and turnover : Since the RAD process emphasizes reuse , many of the program components have already been tested . This reduces overall testing time.However , new components must be tested and all interfaces must be fully exercised.
  6. 6. 6     Requirements planning phase (a workshop utilizing structured discussion of business problems) User design phase – users to participate in the nontechnical design of the system Construction phase – productivity tools, such as code generators, screen generators. Cutover phase -- installation of the system, user acceptance testing and user training RAD Strengths     Reduced cycle time and improved productivity with fewer people means lower costs Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code Uses modeling concepts to capture information about business, data, and processes.
  7. 7. 7 Unit 2: Requirement Engineering Concepts and Methods What is Requirement Engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Types of requirement 1)User requirements • Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers Users are those who use the information system to manage their organizations rather than simply those who work with computers. They are the ones who master the current information system (from information sources, management requirements to the system’s shortcomings) and are future owners of the system. Thus their requirements should be respected while developing any information system. Attention should be paid in the following issues: Easy access: The system must be able to timely access data and manipulation supports. The system: The system must be solid and stable, being able to meet staff’s requirements and provide accurate information, easy to maintain and restructure, quick in identifying and correcting mistakes;
  8. 8. 8 Interface: Suitable with working style of users, stable, easy to control data, independent and flexible, enabling users to approach in different ways. 2)System requirements • A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor The system is developed base on the requirements of the system itself (to help manage an organization) and technical requirements. There are different view points of what information system automation is like, however, we can classify them into groups: view point of the system that will be developed, information expert’s view point and user’s one. These points of view often conflict with one another, at the same time we are required to build up a successful system in which the system, information experts and end users share the same view point. Information system is a system that collects information, manages them and creates information products for its users. Suitable with the general strategies: Small changes in the organization’s development may result in bigger impacts on the information system’s requirements. Therefore, during the system development process, these requirements should be regularly checked for its suitability with the general strategies. Supporting decision maker: Together with hands-on experience, knowledge and anticipating ability, information system plays an important role in supporting decision making process; Competition edge: The more competitive the environment, the more demand for better systems;
  9. 9. 9 Return on Investment: A new information system needs to show financial benefits it can bring, because decisions on investment, development costs and operation costs are based on financial analysis; More advanced evaluation techniques can be applied. These techniques take into consideration issues such as customer support, organizational effectiveness, risk, etc. Overhead control: human resource change will influence staff number, staff skills and workload. In many cases, while human resource structure is unchanged, workload and requirement for staff skills are yet much higher; Supporting operational management: This is clear in preparing detail information, making reports quickly, which contribute to a more flexible and efficient way of management; Improving information communication: Optimizing the flow of information, preparing necessary updated information and providing users with the information; Impact of information products: Information products are final outcomes of the IT system. We need to pay special attention to requirements for information products so as to thorough analysis. These requirements shall be frequently in comparison with general strategies while developing the system; Ability to implement more quickly and better. 3)Software specification • A detailed software description which can serve as a basis for a design or implementation. Written for developers Requirement elicitation techniques- Traditional methods and Modern methods, Verification and validation process.
  10. 10. 10 Software validation Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer Involves checking and review processes and system testing System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system Characteristics of a Good Software Requirements Specification (SRS) Correct An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet. Traceability makes this procedure easier and less prone to error. Unambiguous An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product be described using a single unique term. Complete An SRS is complete if, and only if, it includes the following elements: All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated. Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure. Consistent Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct. An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict. Ranked for importance and/or stability An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement. Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, especially
  11. 11. 11 for life-critical applications, while others may be desirable. Each requirement in the SRS should be identified to make these differences clear and explicit. Verifiable An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. Nonverifiable requirements include statements such as "works well", "good human interface", and "shall usually happen". These requirements cannot be verified because it is impossible to define the terms "good", "well", or "usually". Modifiable An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style. Modifiability generally requires an SRS to Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing; Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS); Express each requirement separately, rather than intermixed with other requirements. Traceable An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. The following two types of traceability are recommended: Backward traceability (i.e., to previous stages of development). This depends upon each requirement explicitly referencing its source in earlier documents. Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.
  12. 12. 12 Unit 3: Design Concept and Methods The software design process Requir ements specif ication Design acti ities v Architectur al design Abstr act specif ication Interface design Component design Data structur e design Algorithm design System architectur e Software specif ication Interface specif tion ica Component specif ication Data structur e specif ication Algorithm specif tion ica Design pr oducts Architectural design Abstract specification Interface design Component design Data structure design Algorithm design Software Design process and principles, Design concepts: Abstraction, Refinement, Modularity, Architecture, Control hierarchy, Structural partitioning, Data structure, Procedure and Data hiding
  13. 13. 13 Design concept 1) Abstraction Wasserman: “Abstraction permits one to concentrate on a problem at some level of abstraction without regard to low level detail. At the highest level of abstraction a solution is stated in broad terms using the language of the problem environment. At lower level, a procedural orientation is taken. At the lowest level of abstraction the solution is stated in a manner that can be directly implemented. Types of abstraction : 1. Procedural Abstraction : A named sequence of instructions that has a specific & limited function Eg: Word OPEN for a door 2. Data Abstraction : A named collection of data that describes a data object. Data abstraction for door would be a set of attributes that describes the door (e.g. door type, swing direction, weight, dimension) 2. Refinement  Process of elaboration.  Start with the statement of function defined at the abstract level, decompose the statement of function in a stepwise fashion until programming language statements are reached.
  14. 14. 14 3.Modularity  In this concept, software is divided into separately named and addressable components called modules  Follows “divide and conquer” concept, a complex problem is broken down into several manageable pieces  Let p1 and p2 be two problems.  Let E1 and E2 be the effort required to solve them -- If C(p1)>C(p2) Hence E(p1)>E(p2) Now-- Complexity of a problem that combines p1 and p2 is greater than complexity when each problem is consider C(p1+p2) > C(p1)+C(p2), Hence E(p1+p2) > E(p1)+E(p2) It is easier to solve a complex problem when you break it into manageable pieces
  15. 15. 15 5 criteria to evaluate a design method with respect to its modularity----- 1)Modular understandability module should be understandable as a standalone unit (no need to refer to other modules) Modular continuity If small changes to the system requirements result in changes to individual modules, rather than system wide changes, the impact of side effects will be minimized Modular protection If an error occurs within a module then those errors are localized and not spread to other modules. Modular Composability Design method should enable reuse of existing components. Modular Decomposability Complexity of the overall problem can be reduced if the design method provides a systematic mechanism to decompose a problem into sub problems
  16. 16. 16 3)Control Hierarchy  Also called program structure  Represent the organization of program components.  Does not represent procedural aspects of software such as decisions, repetitions etc.  Depth –No. of levels of control (distance between the top and bottom modules in program control structure)  Width- Span of control. Fan-out -no. of modules that are directly controlled by another module Fan-in - how many modules directly control a given
  17. 17. 17 module  Super ordinate -module that control another module  Subordinate - module controlled by another Visibility -set of program components that may be called or used as data by a given component Connectivity – A module that directly causes another module to begin execution is connected to it. 4)Software Architecture  Software architecture is the hierarchical structure of program components (modules), the manner in which these components interact and the structure of data that are used by the components.  A set of properties should be specified as part of an architectural design:  Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects) and the manner in which those components are packaged and interact with one another.  Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, reliability, security, adaptability, and other system characteristics.  Families of related systems. the design should have the ability to reuse architectural building blocks. 5)Data Structure Data structure is a representation of the logical relationship among individual elements of data.
  18. 18. 18 • Scalar item – A single element of information that may be addressed by an identifier . • Scalar item organized as a list- array • Data structure that organizes non-contiguous scalar items-linked list 6)data or Information hiding  Information (data and procedure) contained within a module should be inaccessible to other modules that have no need for such information.  Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module. 7)Structural partitioning If the architectural style of a system is hierarchical program structure can be partitioned ----- 1. Horizontal partitioning 2. Vertical partitioning Horizontal partitioning Separate branches can be defined for each major function Eg : 3 partitions
  19. 19. 19 1. Input 2. Data Transformation 3. Output Advantages ◦ Easier to test ◦ Easier to maintain ◦ Propagation of fewer side effects ◦ Easier to add new features Vertical Partitioning ◦ Control and work modules are distributed top down ◦ Top level modules perform control functions ◦ Lower modules perform computations (input processing and output
  20. 20. 20 Modular Design Functional Independence  Functional independence is achieved by developing modules with “single minded” function and an aversion to excessive interaction with other modules.  Measured using 2 qualitative criteria: 1. Cohesion : Measure of the relative strength of a module. 2. Coupling : Measure of the relative interdependence among modules. Cohesion • Strength of relation of elements within a module • Element- Group of instructions or a data definition. • Strive for high cohesion Different types of cohesion : 1. Functional Cohesion (Highest): A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task. Examples of functionally cohesive modules are Compute cosine of an angleCalculate net employee salary 2. Sequential Cohesion : A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next. Eg: Module read and validate customer record  Read record  Validate customer record Here output of one activity is input to the second
  21. 21. 21 3. Communicational cohesion A communicationally cohesive module is one whose elements contribute to activities that use the same input or output data. Suppose we wish to find out some facts about a book For instance, we may wish to  FIND TITLE OF BOOK  FIND PRICE OF BOOK  FIND PUBLISHER OF BOOK  FIND AUTHOR OF BOOK These four activities are related because they all work on the same input data, the book, which makes the “module” communicationally cohesive. 4. Procedural Cohesion A procedurally cohesive module is one whose elements are involved in different and possibly unrelated activities in which control flows from each activity to the next. A piece of coding ties the activities together Eg: Module that averages two completely unrelated tables, TABLE-A and TABLE-B, which both just happen to have 100 elements each. module compute table-A-avg and table-B-avg uses table-A, table-B returns table-A-avg, table-B-avg table-A-total : = 0 table-B-total : = 0 for i = i to 100 add table-A (i) to table-A-total add table-B (i) to table-B-total endfor table-A-avg : = table-A-total/100 table-B-avg : = table-B-total/100 endmodule 5. Temporal Cohesion
  22. 22. 22 A temporally cohesive module is one whose elements are involved in activities that are related in time. A module INITIALIZE initializes many different functions in amighty sweep, causing it to be broadly related to several other modules in the system. module initialize updates a-counter, b-counter, items table, totals table, switch-a, switch-b rewind tape-a set a-counter to 0 rewind tape-b set b-counter to 0 clear items table clear totals table set switch-a to off set switch-b to on endmodule 6. Logical Cohesion A logically cohesive module is one whose elements contribute to activities of the same general category in which the activity or activities to be executed are selected from outside the module. A logically cohesive module contains a number of activities of the same general kind. To use the module, we pick out just the piece(s) we need. 7. Coincidental Cohesion (Lowest) A coincidentally cohesive module is one whose elements contribute to activities with no meaningful relationship to one another. Eg. When a large program id modularized by arbitrarily segmenting the program into several small modules.
  23. 23. 23 Coupling  Measure of interconnection among modules in a software structure  Strive for lowest coupling possible.  Types of coupling 1. Data coupling (Most desirable)  Two modules are data coupled, if they communicate through  parameters where each parameter is an elementary piece of  data.  e.g. an integer, a float, a character, etc. This data item should  be problem related and not be used for control purpose. 2. Stamp Coupling  Two modules are said to be stamp coupled if a data structure is passed as parameter but the called module operates on some but not all of the individual components of the data structure. 3. Control Coupling  Two modules are said to be control coupled if one module  passes a control element to the other module.  This control element affects /controls the internal logic of the  called module  Eg: flags
  24. 24. 24 4. Common Coupling Takes place when a number of modules access a data item in a global data area. 5. Content coupling (Least desirable)
  25. 25. 25 Two modules are said to be content coupled if one module branches into another module or modifies data within another. Eg: int func1(int a) { printf(“func1”); a+=2; goto F2A; return a; } void func2(void) { printf(“func2”); F2A : printf(“At F2A”) }
  26. 26. 26 Unit 6 The Importance of Software Maintenance The Institute of Electrical and Electronics Engineers (IEEE) defines software maintenance as follows: “Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performance, or adapt to a changed environment” This definition of maintenance is a succinct outline of the benefits of software maintenance. Much like your car, software requires periodic refreshes to ensure it continues to run smoothly, a s well as preventative maintenance to reduce the occurrence of problems. Correct Faults Software maintenance packages provided by vendors offer peace-of-mind protection by keeping you covered for bugs and software problems. Like any other product, most software packages are under warranty for a specific period of time. Once these warranties expire, however, you may be required to pay out of pocket for fixes, much like you would for your vehicle. Maintenance programs allow your software to stay in warranty so you do not have to come up with cash should an error occur. Improve Performance Maintenance programs should include an upgrade component. Under a maintenance program, you will be entitled to free upgrades – usually onceper year. These upgrades often address issues reported by other software users and can greatly improve functionality or performance. Considering the overall cost of upgrades over time, this component of software
  27. 27. 27 maintenance is often all that is necessary to make the program worthwhile. Adapt to a Changing Environment Technology and the Business environment are the two of the fastest changing aspects of our world. It is increasingly important to make sure that your business is always taking advantage of the best that your software has to offer and that your software matches the business requirements of the time. Regular updates and maintenance will allow you to keep up with market trends and ensure your business is as efficient and effective as it can be. Predictive Cash Flow The last benefit, but one of the most significant from a financial perspective, is the ability to gain control over your software expenditure. If you are covered for software bugs and receive regular upgrades, your overall IT expenditures will be reduced to a single monthly (or yearly) fee – your maintenance fee. This eliminates the guessing game of IT expenditure and eliminates large unexpected upfront costs down the road. Unit-7
  28. 28. 28 Computer Aided Software Engineering (CASE) What is CASE? Computer-Aided Software Engineering (CASE) is the use of software tools to assist in the development and maintenance of software. Tools used to assist in this way are known as CASE Tools. What is CASE Tool? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process. Computer-Aided Software Engineering tools are those software which are used in any and all phases of developing an information system, including analysis, design and programming. For example, data dictionaries and diagramming tools aid in the analysis and design phases, while application generators speed up the programming phase. CASE tools provide automated methods for designing and documenting traditional structured programming techniques. The ultimate goal of CASE is to provide a language for describing the overall system that is sufficient to generate all the necessary programs needed. Components of CASE Tools CASE Tool are used to support a wide variety of SDLC. CASE Tools are used to help in the project identification and selection, project initiation and planning, and design phacss, and in the implementation and maintenance phases. The components of CASE Tools are categorized into 3 mainly; UpperCASE Tool UpperCASE Tool is a Computer-Aided Software Engineering (CASE) software tool that supports the software development activities upstream from implementation. Uppercase tool focus on the analysis phase (but sometimes also the design phase) of the software development lifecycle (diagramming tools, report and form generators, and analysis tools) LowerCASE Tool LowerCASE Tool Computer-Aided Software Engineering (CASE) software tool that directly supports the implementation (programming) and integration tasks. LowerCASE tools support database schema generation, program generation, implementation, testing, and configuration management. I CASE Tools that integrate both upper and lower CASE, for example making it possible to design a form and build the database to support it at the same time. An automated system development environment that provides numerous tools to create diagrams, forms and reports. It also offers analysis, reporting, and code generation facilities and seamlessly shares and integrates data across and between tools.
  29. 29. 29 Types of CASE Tools The general types of CASE tools are listed below: 1. Diagramming tools: enable system process, data and control structures to be represented graphically. 2. Computer display and report generators: help prototype how systems look and feel. It makes it easier for the systems analyst to identify data requirements and relationship. 3. Analysis tools: automatically check for importance, inconsistent, or incorrect specifications in diagrams, forms, and reports. 4. Central repository: enables the integrated storage of specifications, diagrams, reports and project management information. 5. Documentation Generators: produce technical and user documentation in standard formats. 6. Code generators: enable the automatic generation of program and data base definition code directly from the design documents, diagrams, forms, and reports. What is Quality to CASE Tool? The reason for using case may be very straight forward and practical decision such as being easier to use and makes life better. However from a broader perspective, Quality to using case implies how Case tools have improved the quality of software development. Case tool has improved software development in the following; Improve the quality of the system developed. Increase the speed with which systems are designed and developed. Ease and improve the testing process through the use of automated checking. Improve the integration of development activities via common methodologies. Improve the quality and completeness to documentation. Help standardize the development process. Improve the management of the project. Simplify program maintenance. Promote reusability of modules and documentation. Improve software portability across environments. What is productivity to CASE Tool? And how it helps Software Development. Productivity can be said to be the state or quality of producing something. Or the effectiveness of the productive efforts. Therefore productivity to case can be the achievements gained or the effectiveness of using the CASE technology. Productivity has helped in the development of software in the following ways; Provide new systems with shorter development time. Improve the productivity of the systems development process. Improve the quality of the systems development process. Improve worker skills.
  30. 30. 30 Improve portability of new systems. Improve the management of the systems development process. Functions of a CASE Tool 1. Analysis CASE analysis tools automatically check for incomplete, inconsistent, or in correct specifications in diagrams, forms and reports. 2. Design This is where the technical blueprint of the system is created by designing the technical architecture – choosing amongst the architectural designs of telecommunications, hardware and software that will best suit the organization’s system and future needs. Also designing the systems model – graphically creating a model from graphical user interface, screen design, and databases, to placement of objects on screen 3. Code generation CASE Tool has code generators which enable the automatic generation of program and data base definition code directly from the documents, diagrams, forms, and reports. 4. Documentation CASE Tool has documentation generators to produce technical and user documentation in standard forms. Each phase of the SDLC produces documentation. The types of documentation that flow from one face to the next vary depending upon the organization, methodologies employed and type of system being built. Unit -8
  31. 31. 31 Agile Software Development  Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.  Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks.  Agile methods also emphasize working software as the primary measure of progress Agile process models: 1)DSDM The DSDM (Dynamic Software Development Method) was developed to fill in some of the gaps in the RAD method by providing a framework which takes into account the entire development cycle. The main features of the DSDM method are as follows: 1. 2. 3. 4. 5. User involvement Iterative and incremental development Increased delivery frequency Integrated tests at each phase The acceptance of delivered products depends directly on fulfilling requirements.
  32. 32. 32 2)Adaptive Software Development (ASD) is a software development process that grew out of rapid application development. The characteristics of an Adaptive Software Development (ASD) lifecycle go well with what Software Planner has to offer. Software Planner's comprehensive features include requirements management, test case management, defect management, and project management. Software Planner is an award winning application lifecycle management (ALM) tool that helps Information Technology (IT) departments manage all components of software development including managing customer requirements, project deliverables, test cases, defects, and support tickets. Coupled with collaborative tools like document sharing, team calendars, interactive dashboards, knowledge bases and threaded discussions, teams begin communicating more effectively and begin delivering solutions quickly and with high quality. 3)Scrum Model Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self-management, communication and decision-making. The teams in the organization work together while constantly focusing on their common interests. Scrum involves: Initial appointment of a project manager called the "scrum master." Definition and prioritization of tasks to be done. Planning sessions for each task. Daily meetings among teams.
  33. 33. 33 Identification and evaluation of potential project risks and process pitfalls. Execution of projects in brief, high-intensity, frequent work sessions. Reviews of progress and evaluations of completed projects. Openness to constructive criticism and ideas for improvement. 4) Agile modeling (AM) Agile Modeling (AM) is a chaordic, practice-based methodology for effective modeling of software-based systems. The AM methodology is a collection of practices – guided by principles and values – that are meant to be applied by software professionals on a day-to-day basis. AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler. AM is “touchy-feely” in that it is not hard and fast – think of AM as an art, not a science. An important concept to understand about AM is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. It doesn’t include programming activities, although it will tell you to prove your models with code. It doesn’t include testing activities, although it will tell you to consider testability as you model. It doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as eXtreme Programming (XP), DSDM, SCRUM, the Agile Unified Process (AUP), or theRational Unified Process (RUP). You start with a base process, such as XP or RUP or perhaps even your own existing process, and then tailor it with AM (hopefully adopting all of AM) as well as other techniques as appropriate to form your own process that reflects your unique needs. Alternatively, you may decide to pick the best features from a collection of existing software processes to form your own process. For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities whereas with for RUP projects it describes how to streamline modeling and documentation efforts to improve productivity. 5) Agile unified Process is a simplified version of the Rational Unified Process (RUP) . It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. I've tried to keep the Agile UP as simple as possible, both in its approach and in its description. The descriptions are simple and to the point, with links to details (on the web) if you want them. The approach applies agile techniques include test driven development
  34. 34. 34 (TDD) , Agile Model Driven Development (AMDD) , agile change management , and database refactoring to improve your productivity. Erd for lib.
  35. 35. 35
  36. 36. 36

×