sign in sign up
<<
Home , AccuRev SCM, ArX, Codeville, CVSNT, Dimensions CM, Interleaved deltas

ODRŽAVANJE SOFTVERA

DEFINICIJA “The process of modifying a system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment” • 40-90% of the software life cycle cost

Osnovne faze razvoja softvera:

Uloga odrzavanja u celom zivotnom ciklusu softvera:

TIPOVI ODRZAVANJA:

Faze razvoja i elementi održavanja u agilnom razvoju softvera:

Grupe aktivnosti u održavanju softvera (izvor: Alain April, Jane Huffman Hayes, Alain Abran, and Reiner Dumke: Maturity Model (SMmm): The software maintenance process model)

(izvor: http://www.klariti.com/technical-writing/2011/08/26/software-maintenance-plan/) There are two sides to Software Maintenance Plans – management and technical. . Management issues include aligning with customer priorities, resources, setting up maintenance teams, and costs. . Technical issues include impact analysis, testing, maintainability measurement.

Software Maintenance includes ten activities: 1. Preparation – Describe software preparation and transition activities including the conception and creation of the maintenance plan; describe how to handle problems identified during development and configuration management. 2. Modification – After the application has become the responsibility of the maintenance team, explain how to analyze each request; confirm and check validity; investigate and propose solutions; document the proposal and get the required authorizations to apply the modifications. 3. Implementation – Describe the process for considering the implementation of the modification itself. 4. Acceptance – Describe how the modification is accepted by the maintenance team. 5. Migration – Describe any migration tasks that need to be executed. If the software needs to be moved to another system, outline the steps to do so without impacting its functionality. 6. Transition – Document the sequence of activities to transition the system from Development to Maintenance. 7. Service Level Agreements – Document SLAs and maintenance contracts negotiated by Maintenance. 8. Change Request – Outline the problem-handling process to prioritize, documents and route change and maintenance requests. 9. Modification Request acceptance/rejection – Describe the request including details of the size/effort/complexity. If this is too complex to resolve, outline the steps to route the issue back to the software team. 10. Retirement – This is the final stage in the lifecycle. Describe how to retire the software and the steps to archive any data that may be a by-product of the system.

MODELI ODRZAVANJA SOFTVERA:  QUICK – FIX – je zapravo ad-hoc pristup, čekanje da problem nastupi i korekcija  Boemov model 1983.godine – zasnovan na ekonomskim principima (cost-benefit analiza zahteva za izmenama, izmene su povezane sa resursima koji su potrebni za realizaciju)

 OZBORNOV MODEL – zasniva se na mogućnosti da sve nije idealno, tj. da nisu na raspolaganju svi potrebni podaci, dokumentacija i specifikacije, vec se iterativno realizuje odrzavanje, omogucavajuci pojedinim segmentima da budu izmenjeni.

 Iterativni model unapređenja softvera – iterativni razvoj softvera uz nedovoljno jasne specifikacije koje se novim iteracijama razjasnjavaju I detaljnije opisuju, svaka iteracije radi UPDATE svih dokumenata I svih artefakta (REQUIREMENTS, DESIGN, CODING, TESTING).

 Reuse-oriented model – u okviru održavanja naglasak je na korišćenju gotovih komponenti, tj. prerađivanje starog dela softvera radi ponovnog korišćenja.

SERVICE LEVEL AGREEMENT (SLA) (izvor: https://www.paloaltonetworks.com/cyberpedia/what-is-a-service-level-agreement-sla) A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive. SLAs do not define how the service itself is provided or delivered. The SLA an Internet Service Provider (ISP) will provide its customers is a basic example of an SLA from an external service provider. The metrics that define levels of service for an ISP should aim to guarantee:  A description of the service being provided– maintenance of areas such as network connectivity, domain name servers, dynamic host configuration protocol servers  Reliability – when the service is available (percentage uptime) and the limits outages can be expected to stay within  Responsiveness – the punctuality of services to be performed in response to requests and scheduled service dates  Procedure for reporting problems – who can be contacted, how problems will be reported, procedure for escalation, and what other steps are taken to resolve the problem efficiently  Monitoring and reporting service level – who will monitor performance, what data will be collected and how often as well as how much access the customer is given to performance statistics  Consequences for not meeting service obligations – may include credit or reimbursement to customers, or enabling the customer to terminate the relationship.  Escape clauses or constraints – circumstances under which the level of service promised does not apply. An example could be an exemption from meeting uptime requirements in circumstance that floods, fires or other hazardous situations damage the ISP’s equipment. Though the exact metrics for each SLA vary depending on the service provider, the areas covered are uniform: volume and quality of work (including precision and accuracy), speed, responsiveness, and efficiency. In covering these areas, the document aims to establish a mutual understanding of services, areas prioritized, responsibilities, guarantees, and warranties provided by the service provider. The level of service definitions should be specific and measureable in each area. This allows the quality of service to be benchmarked and, if stipulated by the agreement, rewarded or penalized accordingly. An SLA will commonly use technical definitions that quantify the level of service such as mean time between failures (MTBF) or mean time to recovery, response, or resolution (MTTR), which specifies a “target” (average) or “minimum” value for service level performance. SLAs are also very popular among internal departments in larger organizations. For example, the use of a SLA by an IT helpdesk with other departments (the customer) allows their performance to be defined and benchmarked. The use of SLAs is also common in outsourcing, cloud computing, and other areas where the responsibility of an organization is transferred out to another supplier.

REINŽENJERING SOFTVERA

(izvor: http://www.cs.toronto.edu/~yijun/ece450h/handouts/lecture2.pdf)

UPRAVLJANJE KONFIGURACIJOM SOFTVERA

DEFINICIJA (izvor: https://www.techopedia.com/definition/24583/software-configuration-management-scm)

Software configuration management (SCM) is a discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SCM helps in identifying individual elements and configurations, tracking changes, and version selection, control, and baselining.

SCM is also known as software control management. SCM aims to control changes introduced to large complex software systems through reliable version selection and .

SOFTVERSKI ALATI ZA PRAĆENJE VERZIJA SOFTVERA (Version control softver)

POSTOJI NEKOLIKO MODELA:  Model sa lokalnim podacima - In the local-only approach, all developers must use the same file system.  Klijent- model - In the -server model, developers use a shared single repository.  DISTRIBUIRANI MODEL - each developer works directly with his or her own local repository, and changes are shared between repositories as a separate step.

PRIMERI ALATA: Local *********************** Open source ------ (RCS) – stores the latest version and backward deltas for fastest access to the tip[1][2] compared to SCCS and an improved user interface,[3] at the cost of slow branch tip access and missing support for included/excluded deltas.  Control System (SCCS) – part of ; based on , can construct versions as arbitrary sets of revisions. Extracting an arbitrary version takes essentially the same time and is thus more useful in environments that rely heavily on branching and merging with multiple "current" and identical versions.

Client-server model *********************** Open source ------ Concurrent Versions System (CVS) – originally built on RCS, licensed under the GPL.  CVSNT – cross-platform port of CVS that allows case insensitive file names among other changes  OpenCVS – CVS clone under the BSD license, with emphasis put on security and source code correctness  Subversion (SVN) – versioning control system inspired by CVS[4]  Vesta – build system with a and support for distributed repositories

Proprietary ------ Filesentral – GUI based version control aimed primarily at the non - demographic  AccuRev – source configuration management tool with integrated issue tracking based on "Streams" that efficiently manages parallel and global development; replication server is also available  Autodesk Vault – Version control tool specifically designed for Autodesk applications managing the complex relationships between design files such as AutoCAD and Autodesk Inventor.  CADES - Designer productivity and version control system by International Computers Limited.  Dimensions CM - software change and configuration management system developed by Serena Software that includes revision control.  IBM Rational ClearCase – SCC compliant configuration management system by IBM Rational Software  IBM Configuration Management Version Control (CMVC) – version control system, no longer available.  IBM Rational Team Concert – Collaboration and application lifecycle management platform by IBM Rational Software  IC Manage Global Design Platform (GDP) – design data management for IC design and infrastructure support.  PTC Integrity (Formerly MKS Integrity).  - Around since the 1970s, source and object control for IBM mainframe computers.  Perforce Helix – Free for up to 5 users.  PVCS – originally Polytron Version Control System, developed by Don Kinzer at Polytron, first released in 1985. Now owned by Serena.  Quma Version Control System  Razor (configuration management), integrated suite from Visible Systems  StarTeam – coordinates and manages software delivery process by Micro Focus, formerly ; centralized control of digital assets and activities  Surround SCM – version control tool by Seapine Software.  Team Foundation Server (TFS) - Development software by which includes revision control.  Visual Studio Team Services (VSTS) - Services for teams to share code, track work, and ship software for any language by Microsoft  IBM Rational – SCC compliant integrated change management and task-based configuration management system, proprietary of IBM.  Vault – version control tool by SourceGear (First installation can be used for free)  Visual SourceSafe – version control tool by Microsoft; oriented toward small teams  TeamWork – version control tool by DBmaestro; oriented to DBMs

Distributed model ****************** Open source ------ ArX – written by Walter Landry, started as a fork of GNU arch, but has been completely rewritten  Bazaar – written in Python, originally by Martin Pool and sponsored by Canonical; decentralised, and aims to be fast and easy to use; can losslessly import Arch archives  BitKeeper – was used in kernel development (2002 – April 2005) until it's license was revoked for breach of contract. It was open-sourced in 2016 in an attempt to broaden its appeal again.  – written in Python originally by Ross Cohen; uses an innovative merging algorithm  – written in Haskell and originally developed by David Roundy; can keep track of inter- patch dependencies and automatically rearrange and "cherry-pick" them using a "theory of patches"  DCVS – decentralized and CVS-based  – written by D. Richard Hipp for SQLite; distributed revision control, wiki, and bug- tracking (all-in-one solution) with console and web interfaces. Single portable executable and single repository file.  – written in a collection of Perl, , and various scripts, designed by Linus Torvalds based on the needs of the Linux kernel project; decentralized, and aims to be fast, flexible, and robust  GNU arch  – written in Python as an Open Source replacement to BitKeeper; decentralized and aims to be fast, lightweight, portable, and easy to use  – developed by the Monotone Team; decentralized in a peer-to-peer way  SVK – written in Perl by Kao Chia-liang; built on top of Subversion to allow distributed commits  Veracity - Is another distributed version control system which includes bug tracking and Agile software development tools integrated with the version control features.

Proprietary ------ Code Co-op – peer-to-peer version control system (can use e-mail for synchronization)  Sun WorkShop TeamWare – designed[citation needed] by Larry McVoy, creator of BitKeeper  Plastic SCM – by Codice Software, Inc  Visual Studio Team Services - Services for teams to share code, track work, and ship software for any language by Microsoft

DODATNI MATERIJAL IZ PDF  X. Gonze – Basic concepts of software maintenance, CECAM Lyon February2008  Poglavlje 5 – The Maintenance Process  Thomas M. Pigoski, Software Maintenance Chapter 6, IEEE Trial version 1.0 may 2001.  „Guidance on Software Maintenance“, U.S. Department of Commerce, National Bureau of Standards, Special Publication 500-106, 1983.  Susan Dart, Alan M. Christie, Alan W. Brown: A Case study in Software Maintenance, Technical report CMU/SEI-93-TR-8, Jun 1993.  Hans-Peter Halvorsen, Software Maintenance, slajdovi  Alain April, Jane Huffman Hayes, Alain Abran, Reiner Dumke: Software Maintenance Maturity Model: The software maintenance process model.