Vastus leiad õppematerjalist: Tarkvara kokkuvõte inglise keeles

Tarkvara kokkuvõte inglise keeles (0)

1 Hindamata

Inglise keel - Kõik luuletused, mis on inglise keeles

Esitatud küsimused

Kus vajatakseCMMi?

1. OBJECT -ORIENTED PARADIGM
The Model
•The model defines an abstract view to the problem. This implies that the model focuses only on problem related stuff and that you try to define properties of the problem.
These properties include :

•the data which are affected and

•the operations which are identified by the problem.
Object-oriented Paradigm
•Everything is an object
•A program is a bunch of objects telling each other what to do by sending messages
•Each object has its own memory made up of other objects
•Every object has a type
•All objects of a particular type can receive the same messages
Domain Model
•A domain model does not represent the entire domain as it is in the real world. It includes only the concepts that are needed to support the application .
Object
•Is a partitioned area of memory where object code is stored
•The area of memory is protected
•This code can function relatively independently of other objects
•Can be used by many parts of one program or by parts of many programs
Message Passing
•The mechanism by which objects communicate
•The object can accept or reject the message
•From outside the object it appears to be active data
•From inside the object the data is passive --the message tells the object what to do with the data
Classes
•A very basic concept in OOP
•It is a template for creating actual, functioning objects of a given type
•In some cases a class is an object
•simile
–A class is a blueprint or DNA for creating a cow. But
– it is the actual cow that produces milk , not the cow class
–All cows are made from the cow class
Methods
•Messages = Requests in avenue
•A request is just that: a requestfor an object to do something .
•Something ranges from changing properties (like gender) to doing something like copying itself or printing.
•Properties are “things”in the object that can be changed.
Instansion
•A class is instantiated when it is used to stamp out one or more objects of its type
•Objects that are created from a given class are called instances of that class
•Encapsulation means that the properties and methods of an object are not directly accessible to the outside world.
•Inheritance is the ability to create new classes based on an existing class. The new class inherits all the properties and methods and events of the base class, and can be customized with additional properties and methods.
•Polymorphism is the ability of different classes to define properties or methods with the same name. Polymorphism is essential to object-oriented programming because it allows you to call methods with the same names, no matter what type of object is in use at the moment.
2. COMPONENT TECHNOLOGY – THE PROBLEM
The Problem
• Today , anything and anyone must be net-enabled.
•Automated business processes , products , and software systems need to evolve in „e-Time“.
•Everything must be changeable, extensible, adaptable.
• Quality is an important issue .
Architectural consequences of these requirements :
•Software should not be designed as monolithic unit but partitioned into composableservices that can be spontaneously connected and orchestrated by business/technical processes (component-based software).
•„Software entropy“should be maximized: loosely coupling between peers,decentralized information access , reflective approaches (Just-in-Time Integration).
•Software must be e-enabled.
Application Partioning
• Solutions consist of collections of components .
•Components are divided into multiple packages.
•Packages can work with each other across a network through ObjectRequestBroker(ORB).
•This application partitioning is transparent to the component developer .
3. COM Principles:
Rigorous Encapsulation: - no leakage of implementation details; – All object manipulation through strict interfaces.
Polymorphism: – via multiple interfaces per class; – “Discoverable”: Query Interface
COM Model – how the techogy is used.
COM ORB = COM Runtime – how is it implemented.
COM is efficianet and scalable: 28 bytes headers; keep-alive messages.
ActiveX: marketing name for a set of technologies and services , all based on COM(model,orb)
Active components - controls: COM-component with designed time, optimized for download and execute; self-registering; support in multiple languages.
OLE:1.0 – object and container (server/ client ); object application runs in own window. 2.0 – visual editing,COM based, controls = *.ocx files.
.NET: Process : source code->compiler-> metadata ->CLR-> result .
CLR: .Net execution environment-execution management ; provide services.
Managed Code provides: cross-laguage integration; auto memory services; self- described objects; compile once -run everywhere.
Metadata: describe components, objects and execution conditions ; provide garbage collection .
MSIL=Microsoft Intermediate language (between compiler and JIT)
JIT=Just in Time compiling. Part of data compile only in run-time when it is needed.Loader creates stub for every method .After,querys go to mashinecode.Convert verification-safe code.
Assembly is a partially compiled code library for use in deployment , versioning and security . Two types , process assemblies (EXE) and library assemblies (DLL). Process assembly use classes from library assemblies.
Summary:assembly=component;MS computing distributes among servers and clients via .Net assemblies; .NET more versatile than DCOM+; Asseblies interoperable among MS languages.
4. Relationships
I Association (Models a semantic connection among classes)
– Aggregation (A special form of association that models a whole -part relationship between an aggregate (the whole) and its parts)
– Composition (A form of aggregation with strong ownership and coincident lifetimes)
II Dependency
III Generalization
IV Realization
I Association: Multiplicity and Navigation
• Multiplicity defines how many objects participate in a relationships
– The number of instances of one class related to ONE instance of the other class
– Specified for each end of the association
• Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction
– If navigation is restricted, an arrowhead is added to indicate the direction of the navigation
Association: Multiplicity
• Unspecified
• Exactly one 1
• Zero or more (many, unlimited) 0..*
• One or more 1..*
• Zero or one 0..1
• Specified range 3..7
• Multiple, disjoint ranges 2, 5..7
II Relationships: Dependency
• A relationship between two model elements where a change in one may cause a change in the other
• Non-structural, “using” relationship
III Relationships: Generalization
• A relationship among classes where one class shares the structure and/or behavior of one or more classes
• Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses
– Single inheritance
– Multiple inheritance
• Generalization is an “is-a-kind of” relationship
What Gets Inherited?
• A subclass inherits its parent ’s attributes, operations, and relationships
• A subclass may:
– Add additional attributes, operations, relationships
– Redefine inherited operations (use caution!)
• Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy
IV Relationships: Realization
• One classifier serves as the contract that the other classifier agrees to carry out
• Found between:
– Interfaces and the classifiers that realize them
– Use cases and the collaborations that realize them
5. Unified Modeling Language
Use Case Analysis is a technique to capture business process from user ’s perspective.
What is the UML?
• UML stands for Unified Modeling Language
• The UML combines the best of the best from
– Data Modeling concepts (Entity Relationship Diagrams )
– Business Modeling (work flow)
– Object Modeling
– Component Modeling
• The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software- intensive system
• It can be used with all processes, throughout the development life cycle , and across different implementation technologies
UML 2.0-is avisual modeling lang.,describes the specification and design of a soft intensive system via visual models
UML2.0 history: fragmentation (the method wars), unification (booch, rumbaugh, Jacobson), standardization (UML1.1) ,industrialization. =>1.3.01.4.1.5 2.0
AN Architectural representation: logical ,implementation, process, deployment views
Use Case Diagramm shows all the ways of using the system; classifiers can now own use cases.
Associated Diagrams: activity d.-can be used to model interaction between scenarios.
Activity Diagram :
Focus on flow of activities involved in a process.
Significant changes from UML1.X-now address real time flow,incorporated Petri Net concepts
-decompose activity into multiple actions
-activity parameters and pins
Useful because they focus on workflow-don’t have to reference a prticular object so ideal to map complex alternarive flows in a use case.
Visual map of a set of activities and possible transitions between them –activities by one or more operations.
Activity Modeling
•The sequence and conditions for coordinating other behaviors
• … using secondary constructs to show which classifiers are responsible for those behaviors.
• Focus is on what tasks need to be done , in what order , rather than who/what performs each task
Interfaces UML1.X supports only in 1 direction, UML2.0-bidirectional interface.
Package Diagrams-organises the model,dependency indicates a usage relationship between contents of the packages,use it to model the high-level organization of the system,indicate visibility on owned elements,import from packages,supports package merge.
Ports -NEW. -defines as interaction point on a classifier (between it and its enviroment)
Composition 2.0 PORTS=public parts.
Composite Structure Diagram. UML 1.x only had composition to model internal structure, UML2.0 introduces this d. to model “hidden”detail.
UML – Modeling Techniques
• Business rules
• Change cases
• Class responsibility collaborator (CRC) models
• Constraints
• Essential use case models
• Essential user interface prototypes
• Persistence/data models
• Technical requirements
• UML activity diagrams
• UML class models
• UML collaboration diagrams
• UML component diagrams
• UML deployment diagrams
• UML sequence diagrams
• UML state chart diagrams
• UML use case models
• User interface flow diagrams
• User interface prototypes
UML põhidiagrammid :
• Staatika diagrammid
• Klassidiagramm
• Use Case diagramm
• Dünaamika diagrammid
– Suhtlusdiagrammid
• Jadadiagramm (sequence diagram)
• Koostöödiagramm (collaboration diagram)
– Elutsükli dikagrammid
• Seisundidiagramm (state diagram)
• Tegevusdiagramm (activity diagram)
• Realisatsiooni diagrammid
• Komponendidiagramm (component diagram)
• Rakendusdiagramm (deployment diagram)
UML Concepts
• The UML may be used to:
– Display the boundary of a system & its major functions using use cases and actors
– Illustrate use case realizations with interaction diagrams
– Represent a static structure of a system using class diagrams
– Model the behavior of objects with state transition diagrams
– Reveal the physical implementation architecture with component & deployment diagrams
– Extend your functionality with stereotypes
Object Orientation:
- Encapsulation
- Abstraction
- Hierarchy
- Modularity
Class Compartments
• A class is comprised of three sections
– The first section contains the class name
– The second section shows the structure (attributes)

The third section shows the behavior (operations)

The Relationship Between Classes and Objects
• A class is an abstract definition of an object
– It defines the structure and behavior of each object in the class
– It serves as a template for creating objects
• Objects are grouped into classes
Polymorphism - The ability to hide many different implementations behind a single interface
What is an Interface?
• Interfaces formalize polymorphism
• Interfaces support “plug-and-play” architectures
What is a Component?
• A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture
• A component may be
– A source code component
– A run time components or
– An executable component
What is a Package?
• A package is a general purpose mechanism for organizing elements into groups
• A model element which can contain other model elements
• Uses
– Organize the model under development
– A unit of configuration management
What is a Subsystem?
• A combination of a package (can contain other model elements) and a class (has behavior)
• Realizes one or more interfaces which define its behavior
Subsystems and Components
• Components are the physical realization of an abstraction in the design
• Subsystems can be used to represent the component in the design
6. WATERFALL MODEL
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance .
Why a Pure Waterfall Process is Usually Not Practical
- Don’t know up front everything wanted and needed
o Usually hard to visualize every detail in advance
- We can only estimatethe costs of implementing requirements
o To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones
o We will probably need to modify requirements as a result
- We often need to execute intermediate builds
o Stakeholders need to gain confidence
o Designers and developers need confirmation they're building what’s needed and wanted
- Team members can't be idle while the requirements are being completed
o Typically put people to work on several phases at once
Waterfall Process Assumptions
•Requirements are known up front before design
•Requirements rarely change
• Users know what they want, and rarely need visualization
•Design can be conducted in a purely abstract space, or trial rarely leads to error
•The technology will all fit nicely into place when the time comes (the apocalypse)
•The system is not so complex. (Drawings are for wimps)
Waterfall Process Limitations
•Big Bang Delivery Theory
•The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced.
• Late deployment hides many lurking risks:
–technological (well, I thought they would work together...)
–conceptual (well, I thought that's what they wanted...)
–personnel ( took so long, half the team left)
–User doesn't get to see anything real until the very end, and they always hateit.
–System Testing doesn't get involved until later in the process.
Test- Action -Cycleas optimisationcycle
•Each individual optimisation cycle consists of a test and an action component which are suitably coupled.
•An important dimension of the optimisation cycle is its length , i.e. the time required to complete the cycle once.
•Depending on the nature of the activity and the testing, the length can be anything from a matter of a few seconds to up to possibly several years .
•The longer this period , the more costly the optimisation cycle.
•It is the aim of user-oriented software development to incorporate an as efficient optimisation cycle as possible into software development procedures
7. Capability Maturity Model (CMM)
Capability Maturity Model (CMM) broadly refers to a process improvement approach that is based on a process model.
The Capability Maturity Model can be used to assess an organization against a scale of five process maturity levels. Each level ranks the organization according to its standardization of processes in the subject area being assessed. The subject areas can be as diverse as software engineering , systems engineering, project management, risk management, system acquisition, information technology (IT) services and personnel management.
Total Quality Management
•Total Quality Management (TQM) is the application of quantitative methods and human resources to improve :

–the material and services supplied to an organization

–all the processes within an organization

–the degree to which the needs of the customer are met, now and in the future
Põhimõisted
Tarkvaraprotsessi võimekus (software process capability) näitab, millist tulemit võib loota organisatsiooni järgmiselt tarkvaraprojektilt.
Tarkvaraprotsessi tulemuslikkus (software process performance ) esindatab tegelikku tulemit, mis saadi tarkvaraprotsessi järgides .
Tarkvaraprotsessi küpsus (software process maturity) on määr, milleni protsesson määratletud, juhitud , mõõdetud, kontrollitud – on tarkvaraprotsessi tõhususe mõõt.
Immature versus Mature Software Organizations
•In an immature software organization, software processes are generally improvised by practitioners and their management during the course of the project.
• Even if a software process has been specified, it is not rigorously followed or enforced. The immature software organization is reactionary, and managers are usually focused on solving immediate crises (better known as fire fighting).
•Schedules and budgets are routinely exceeded because they are not based on realistic estimates. When hard deadlines are imposed , product functionality and quality are often compromised to meet the schedule .
•In an immature organization, there is no objective basis for judging product quality or for solving product or process problems. Therefore , product quality is difficult to predict . Activities intended to enhance quality such as review sand testing are often curtailed or eliminated when projects fall behind schedule.
•A mature software organization possesses an organization-wide ability for managing software development and maintenance processes.

–The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process.

–The processes mandated are usable and consistent with the way the work actually gets done. These defined processes are updated when necessary , and improvements are developed through controlled pilot- tests and/or cost benefit analyses.

–Roles and responsibilities within the defined process are clear throughout the project and across the organization.
The Five Levels of Software Process Maturity
I Initial
II Repeatable
III Defined
IV Managed
V Optimizing
Organisatsiooni küpsustastmed
•CMM määratleb organisatsiooni tarkvaraarenduse 5 küpsustaset:
1.tase – Initial – metoodika puudumine (=häkkerlus, “põõsametoodika”), organisatsioonon mitteküps. Mitteküpses organisatsioonis pole enamasti tarkvaraprotsess määratletud. Ja isegi kui mingi protsess on määratletud, ei peeta sellest kinni. Mitteküps organisatsioon lahendab probleeme nende esilekerkimise järjekorras, tegevus seisneb peamiselt “tulekahjude kustutamises”. Kuna tähtaegadest ei suudeta kinni pidada, on meeskonnal vaja pidevalt sooritada töökangelastegusid. Ka (juhuslikult) õnnestunud projekti kordamiseks peaks meeskond ja selle liikmete rolled samad olema. Seega, 1se taseme puhul võime küll rääkida üksikisikute võimekusest ja küpsusest, mitte aga organisatsiooni küpsusest.
2.tase – Repeatable – korratav. Sellel tasemel on määratletud tarkvaraprojekti juhtimise poliitikad ja nende poliitikate elluviimise protseduurid määratletud. Uute projektide plaanimine ja juhtimine toetub kogemustele analoogsete projektidega. Protsessid on praktikas läbiproovitud, dokumenteeritud, kohustuslikud, on läbi viidud opposed ja treeningud . On loodud tingimused protsesside edasiseks täiustamiseks. Paneme tähele, et tunduvalt on vähenenud sõltuvus üksikisikust, mis tõsisemate ettevõtmiste korral (nt. finantsinstitutsioonid) on turvalisuse seisukohalt äärmiselt oluline.
3. tase – Defined – määratletud. Sellel tasemel on kehtestatud ja dokumenteeritud organisatsiooni standardprotsess tarkvara arendamiseks . Organisatsiooni standardprotsess sisaldab nii tarvaratehnika-kui ka juhtimisprotsesse, mis on terviklikult integreeritud. Organisatsiooni standardprotsessi haldamiseks on moodustatud tarkvaratehnika protsesside grupp; on evitatud kogu organisatsiooni hõlmav õppe- ja treeningprogramm, et tagada kõigi töötajate ja juhtide vastavad teadmised ja oskused. Organisatsiooni standardprotsessi kohandatakse vastavalt konkreetsete projektide eritingimustele/-nõuetele–project ipool tmääratletud tarkvaraprotsess. 3nda taseme organisatsioonides on projekti funkstionaalsus, ajagraafik ja maksumus täielikult kontrollitav.
4. tase – Managed – juhitav. Sellel tasemel organisatsioon seab kvantitatiivsed kvaliteedinõuded nii tarkvaratoodetele kui ka -protsessidele. Üle kõikide projektide oluiliste protsesside on olemas mõõdetud tootlikkuse ja kvaliteedit mõõt. On loodud üleorganisatsiooniline protsesside andmebaas, mida kasutatakse protsesside analüüsiks. Projektide parameetrid on määratletavad, kõikumised tootlikkuses, tähtaegades jmt. on reeglina tühised. 4nda taseme organisatsioonid tagavad tarkvaratoodete kõrge kvaliteedi.
5. tase – Optimizing – optimeeriv. 5nda taseme organisatsioon täiustab pidevalt oma protsesse. Organisatsioonil on vahendid protsesside nõrkuste selgitamiseks ja nende preventiivseks parendamiseks. Andmeid tarkvaraprotsessi efektiivsusest kasutatakse uute tehnoloogiate ja protsesside analüüsiks. Tehnoloogia ja protsesside muudatused on planeeritud ja viiakse läbi vastavate protseduuride alusel.…,
Kus vajatakseCMMi?
•väga suured programmid, mille täitmisest võtab osa palju organisatsioone
•virtuaalprojektid või -organisatsioonid
•geograafiliselt hajutatud projektid
•arendusorganisatsioonid
(research and development, R&D)
8. The OPEN Process
•The OPEN consortium, a group of individuals and organizations promoting and enhancing the use ofobject-oriented technology, has developed the OPEN Process, a comprehensive software process.
•Likethe Unified Process, the OPEN Process is aimed at organizations using object and componenttechnology, although it can easily be applied to other software development technologies.
•The OPEN Process supports the UML notation, and the ObjectModeling Language (OML) notation, and any other OO notation to document the work products theOPEN process produces.
•The activities of the OPENare subject to stated contracts, making OPEN a responsibility-driven process.
The OPEN
•Cross-project activities-this is a major departure from what you've seen in the Unified Process: the lifecycle of the OPEN Process explicitly includes activities outside of the scope of a single project.
•This is called programme management in the OPEN Process, a programme being a collection of projects and/or releases of an application or suite of applications.
•Common programme management activities would include organization-wide architectural modeling efforts, process improvement efforts, and standards/guidelines development and support.
•This sort of effort is often called Enterprise Managementor Infrastructure Management within software organizations.
•It has strong support for process modeling, project management and requirements capture as well as traditional OO "analysis and design".
Strengths of the OPEN Process
1. It is the most comprehensive of the three processes presented, including a cradle-to-grave approach to the lifecycle of a project and a multi -project view to software that reflects the actual environment of most organizations.
2. It is the brainchild of a wide variety of practitioners and academics, all of whom are coming to the table with different experiences, skill sets, and backgrounds. This breadth of talent is one reason for the OPEN Processes comprehensiveness and has resulted in a smorgasbord of development techniques from which to choose .
The OPEN Process serious drawback :
•Ineffectivemarketing.
•Remember the illfated Object Modeling Language(OML) from the OPEN Consortium, the notation that ran against the Unified Modeling Language (UML) several years ago in the race to become the industry standard notation?
•The OML was superior in many respects to the UML, but it unfortunately didn't garner the market mindshare that the UML did.
•It is possible that once again the best candidate will be out marketed by the second best, which more often than not is the norm in our industry.
9. RUP— The Approach
The Spirit of the RUP – Essential Principles
– Attack major risks early and continuously…or they will attack you
– Ensure that you deliver value to your customer
– Stay focused on executable software
– Accommodate change early in the project
– Baseline an executable architecture early on
– Build your system with components
– Make quality a way of life, not an afterthought
The Iterative Approach
• It accommodates changing requirements
• Integration is not one "big bang" at the end of a project
• Risks are usually discovered or addressed during early integrations
• Management has a means of making tactical changes to the product
• Reuse is facilitated
• Defects can be found and corrected over several iterations
• It is a better use of project personnel
• Team members learn along the way
• The development process itself is improved and refined along the way
The RUP—A Well-Defined Software Engineering Process
• Dynamic structure – time dimension
• Static structure – describes how process elements—activities, disciplines, artifacts, and roles—are logically grouped into core process disciplines
10. Extreme Programming Practices
Has 12 practices, grouped into four areas, derived from the best practices of software engineering:
Fine scale feedback
Pair programming
Planning Game
Test driven development
Whole team
Continuous process
Continuous Integration
Design Improvement
Small Releases
Shared understanding
Coding Standards
Collective Code Ownership
Simple Design
System Metaphor
Programmer welfare
Sustainable Pace
11. Extreme Programming - Four Variables
Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are:
Communication
Simplicity
Feedback
Courage
Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.
Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow , next week, or next month . Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the (quality of) communication. A simple design with very simple code could be easily understood by most programmers in the team.
Within Extreme Programming, feedback relates to different dimensions of the system development:
Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.
Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements (aka user stories ). To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment.
Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.
13. Extreme Programming - Estimating User Stories
Usage
As a central part of the planning game, user stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers.
When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written.
Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it. Without a precise formulation of the requirements, unconstructive prolonged arguments may arise when the product is to be delivered.
Benifits
XP favours face -to-face communication over comprehensive documentation and quick adaptation to change instead of fixation of the problem. User stories achieve this by:
Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
Allowing developer and client to discuss requirements throughout the project lifetime
Needing very little maintenance
Only being considered at the time of use
Maintaining a close customer contact
Allow projects to be broken into small increments
Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
May be easier to estimate development effort
Limitations
Some of the limitations of user stories in XP:
Without accompanying acceptance tests, they are open to interpretation which makes them difficult to use as the basis for agreement
They require close customer contact throughout the project which in some cases may be difficult or may be unnecessary overhead
Can have difficulty scaling to large projects.
Rely more on competent developers
User stories are regarded as conversation starters. Unfortunately they may not capture where the conversation ended and fail to serve as a form of reliable documentation of the system.
14. Feature-Driven Development (FDD)
Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner .
FDD 5 Parts
an object model (more shape than detail)
major future sets
the development plan
Sequence diagram (more detail than shape)
Client-valued functionality
16. FDD Best Practices
•Probleemvaldkonna modelleerimine -DomainObjectModeling
•Funktsioonipõhine arendus -DevelopingbyFeature
•Koodi personal omandus –Individual Class(Code) Ownership
•Funktsioonitiimid –Feature Teams
•Koodi läbivaatused -Inspections
•Regulaarsed koosted – Regular Builds
•Konfiguratsioonihaldus –Configuration Management
•Tulemite näitlikustamine -Reporting/Visibility of Results
18. Short Comparison FDD vs XP
•Traditional heavy processes with long ‘analysis phases’areunworkable for projects running on internet time; business requirements are changing monthly if not weekly.
•Software continues to be delivered late and over budget with less useful function than first envisioned.
•Both FDD and XP are designed to enable teams to deliver results quicker without compromising quality.
•Both processes are highly iterative and results oriented.
•They are both people focused instead of document focused (no more thousand page specifications to write).
•Both dismantle the traditional separation of domain and businessexperts/analysts from designers and implementers; analysts are dragged out of their abstractions and put in the same room as developersand users.
•These new processes, together with new tools and techniques are enabling and encouraging analysis, design, code, test and deployment to be done concurrently.
Where do FDD and XP differ ?
1.Team sizes
–“XP is designed to work with projects that can be built by teams of two to ten programmers, that aren ’t sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day.”
–FDD was first used with a team of 16-20 developers of varying abilities, cultural backgrounds and experience : four chief programmers (CP's), sixteen class owners split into User Interaction (UI), Problem Domain (PD) and Data Management (DM) teams. FDD is designed to scale to much larger team sizes.
2. The enormous difference between XP and FDD is FDD'sadditional development of an overall domain object model.
•XP uses the analogy of driving a car -driving requires continual little course adjustments, you cannot simply point the car in the rightdirection and press the accelerator.
•A domain object model is the map to guide the journey; it can prevent you from driving around in endless circles.
•The domain object model provides an overall shape to which to add function, feature by feature.
3.Collective Ownership or Class Ownership:
a. XP claims three benefits from collective code ownership:
•We avoid waiting for someone to make a change we need in their code.
•Overly complex code is eliminated because anyone who finds such code will try to simplify it. Knowing this, developers are less likely to add complexity that they cannot justify.
•Collective ownership spreads knowledge of a system throughout the team reducing risk if a critical team member leaves.
b. Feature teams also solve these problems, while keeping the well established benefits of individual code ownership:
•By definition, all the owners of classes needing updates for the development of a particular feature are members of the feature team. In other words, the feature team owns all the code that needs changing for a particular feature. This minimizes the waiting for someone else to modify their code.
•All low-level design in FDD is done within feature teams (Design By Feature). The irritating 'development by surprise' problem where a developer delivers code that is different from agreed design is caught at code inspection by the feature team and rejected. Overly complex code is caught in the same way, before it enters the system.
•Although class owners work only on the classes they own, owners of closely associated classes frequently work in the same feature team. They get to know those closely associated classes. Knowledge is clustered rather than randomly scattered.
4. Testing
•Correctness in XP is defined by the running of unit and functional tests.
•FDD takes unit testing almost for granted as part of Build By Feature.
•FDD does not define the mechanisms or level of formality for unit testing;
–it leaves that to the chief programmer to do what is appropriate.
•It is acceptable to use XP unit testing techniques in an FDD environment.
–Where continuous or regular system builds are performed, it certainly makes sense to have a growing set of tests that can berun against a new build.
5. Reporting
•XP leaves tracking to the project managers, encouraging them to minimize the overhead of collecting data and use large visible wall charts.
•In contrast, Tracking By Feature in FDD describes a low-overhead, highly accurate means of measuring progress and provides the data to construct a large variety of practical, useful, progress charts and graphs.
19. Scrum is a project management method.
The approach was first described by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). They noted that projects using small, cross-functional teams historically produce the best results, and referred to this as the "rugby approach". In 1991, DeGrace and Stahl, in "Wicked Problems, Righteous Solutions" referred to this approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka. Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods, in the early 1990's. At the same time, Jeff Sutherland , John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and were the first to call it Scrum. Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA '96 in Austin, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. Schwaber teamed up with Mike Beedle in 2001 to write up the method in the book Agile Software Development with SCRUM.
Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach: Scrum of Scrums.
Characteristics of Scrum
A product backlog of prioritized work to be done;
Completion of a fixed set of backlog items in a series of short iterations or sprints;
A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
A brief sprint planning session in which the backlog items for the sprint will be defined.
A brief sprint retrospective, at which all team members reflect about the past sprint.
Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called Requirements Churn), and that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
21. RUP: Dynamic and Static Structures
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, since 2002 a division of IBM.
The RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.
What Is the Rational Unified Process?
• The RUP is a software development approach that is
– iterative,
– architecture-centric, and
– use-case-driven
• The RUP is a well-defined and well-structured software engineering process
• The RUP is also a process product that provides you with a customizable process framework for software engineering
Principles and best practices
RUP is based on a set of software development principles and best practices, specifically:
Develop software iteratively
Manage requirements
Use component-based architecture
Visually model software
Verify software quality
Control changes to software
22-23. The Dynamic Structure of the Rational Unified Process
The Dynamic Structure of the Rational Unified Process
• Inception ( Understand what to build)
• Elaboration (Understand how to build it)
• Construction (Build a beta version of the product)
• Transition (Build the final version of the product)
Inception (начало)
• Establish a good understanding of what system to build by getting a high-level understanding of all the requirements and establishing the scope of the system
• Mitigate many of the business risks,
• Produce the business case for building the system
• Get buy-in from all stakeholders on whether to proceed with the project
Inception Phase
– Objectives:
– Understand the scope of the project
– Build the business case
– Get stakeholder buy-in to move ahead
– Milestone:
– Lifecycle Objective Milestone (LCO)
Software Requirements (требования)
- functional requirements
- nonfunctional requirements
- design constraints
Elaboration
• Take care of many of the most technically difficult tasks:
– Design, implement, test, and baseline an executable architecture, including subsystems, their interfaces, key components, and architectural mechanisms, such as how to deal with inter -process communication or persistency
– Address major technical risks, such as resource contention risks, performance risks, and data security risks, by implementing and validating actual code
Elaboration (разработка) Phase
– Objectives:
– Mitigate major technical risks
– Create a base lined architecture
– Understand what it takes to build the system
– Milestone:
– Lifecycle Architecture Milestone (LCA)
Construction
• Do most of the implementation as you move from an executable architecture to the first operational version of your system
• Deploy several internal and alpha releases to ensure that the system is usable and addresses user needs
• End the phase by deploying a fully functional beta version of the system, including installation and supporting documentation and training material (although the system will likely still require tuning of functionality, performance, and overall quality)
Construction Phase
– Objective:
– Build the first operational version of the product
– Milestone:
– Initial Operational Capability Milestone (IOC)
Transition
• Ensure that software addresses the needs of its users
• This includes testing the product in preparation for release and making minor adjustments based on user feedback
• At this point in the lifecycle, user feedback focuses mainly on fine-tuning the product, configuration, installation, and usability issues ; all the major structural issues should have been worked out much earlier in the project lifecycle
Transition Phase
– Objective:
– Build the final version of the product and deliver it to the customer
– Milestone:
– Product Release Milestone (PR)
25. Enterprise Unified Process
The Enterprise Unified Process (EUP) is an extension of the Rational Unified Process developed by Scott W. Ambler the Practice Leader in Agile development at IBM Corporation.

Phases

The Unified Process defines four project phases:

Inception
Elaboration
Construction
Transition

To these EUP adds two additional phases:

Production
Retirement

Disciplines

The Rational Unified Process defines nine project disciplines:

Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment
Configuration and Change Management
Project Management
Environment

To these EUP adds one additional project discipline:

Operations and Support

and seven enterprise disciplines:

Enterprise Business Modeling
Portfolio Management
Enterprise Architecture
Strategic Reuse
People Management
Enterprise Administration
Software Process Improvement

Best Practices of EUP

The EUP provide following best practices:

Develop iteratively

Manage requirements

Proven architecture

Modeling

Continuously verify quality.

Manage change

Collaborative development

Look beyond development.

Deliver working software on a regular basis

Manage risk
26. Open Unified Process (OpenUP)
The Open Unified Process (OpenUP) is a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. It provides best practices from a variety of software development thought leaders and the broader software development community that cover a diverse set of perspectives and development needs.
OpenUP preserves the essential characteristics of RUP / Unified Process, which includes iterative development, use cases and scenarios driving development, risk management, and architecture-centric approach.
The most agile and lightweight form of OpenUP, OpenUP/Basic, targets smaller and co- located teams interested in agile and iterative development. Small projects constitute teams of 3 to 6 people and involve 3 to 6 months of development effort.
28. CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes.
Roots of CMMI
The CMMI is the successor of CMM. CMM was developed from 1987 until 1997. In 2002 version 1.1 of the CMMI was released : v1.2 followed in August 2006. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework. It was created by members of industry, government and the SEI
29-30. CMMI Representations
• The Continuous Representation
– The continuous representation is based on process capability - the range of expected results that can be achieved by following a process.
– Process improvement is measured in capability levels that relate to the achievement of specific and generic goals in each process area.
– The continuous representation provides flexibility for organizations to choose which processes to emphasize for improvement, as well as how much to improve each process.
– It enables selection of the order of process improvement that best meets the organization’s business objectives and that most mitigates risk.
• The Staged Representation
– The staged representation is based on organizational maturity—the combined capabilities of a set of related processes.
– Organizational improvement is measured in maturity levels.
– This representation has a recommended order for approaching process improvement, beginning with basic management practices and progressing along a proven path.
32. Capability Profile
• In a continuous appraisal, each processarea is rated at its own capability level.
• An organization will most likely have different process areas rated at different capability levels.
• The results can be reported as a capability profile.
41. Crystal Clear
Crystal Clear is a member of the Crystal family of methodologies as described by Alistair Cockburn and is considered an example of an agile or lightweight methodology.
Crystal Clear can be applied to teams of up to 6 or 8 colocated developers working on systems that are not life-critical. The Crystal family of methodologies focus on efficiency and habitablity as components of project safety .
Crystal Clear focuses on people, not processes or artifacts.
Crystal Clear contains the following properties (the first three are required):
Frequent Delivery of Usable Code to Users (required)
Reflective Improvement (required)
Osmotic Communication Preferably by Being Co-Located (required)
Personal Safety
Focus
Easy Access to Expert Users
Automated Tests, Configuration Management, and Frequent Integration

42-43. Goal Development in SW Development process. Delivery Process in SW Development process
A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
Iterative processes
Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.
Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software[ citation needed], but have the drawback from a business perspective that they do not provide long-term planning capability[citation needed]. In essence, the Agile approach claims it will provide the most bang for the buck , but won't say exactly when that bang will be or how big a buck will ultimately be required.
44. Agile SW Delivery

AGILE METHODOLOGIES(A.M.)

Agile alliance created in 2001.
Manifesto:goal is to develope new better methods;important are people and their relations instead of process;working software than full documentation;client participation.
Main printsiples:honesty to client; individual abilities; team-work; adaptation(feedback service); simplification.
A.M. attempt to identify a few rules and then evolve them to meet spec. problems through individual and group feedback.
Major A.M.: Crystal methods, Feature Driven Development, Extreme Programming (most attantion attractive)…
XP: make working programm, which satisy present needs. No future orientation.Cost of project doesn’t grow from beginning to end. Project takes 2-3 month.
XP values: communication, simplicity, feedback, courage.
Planning: goal:to mark system features and clientstories(client-side system wanted features) of next iteration;realisation time planning;client fulfills goal.
Small releases:2-3weeks,as smaller as better-the way to ensure expectations development,small release cycle are workable, because most important built first.
Simple design:runs tests;no duplicate code; states programmers intent clearly for all code;fewest possible classes and methods.
XP design is continuous process happening on conseptual and physical layers.
Tests is written before coding;Client writes test to verify the story;programmers write tests to verufy code mustakes.
Pair programming:one writes code,another verify.Both use one computer.-> less mistakes.
Refactoring: technique to improve code without changing functionality.
Collective ownership: means that application code can chenge anyone at anytime, so that responsibility shares.
Continuous programming:as case is programmed, it is itegrated into programm few times a day.
XP programmers have strictly 40-hours a week work,because of impressive development speed and continuous stress.
On-site customer: always present for consulting(better in one room with programmers).
All team programmers should use code standards to produce the code.
XP principles: fine scale feedback(onsite customer, test driven development, pair programming); continuous process(small releases, refactoring, continuous integration); shared understanding(simple design, collective code, coding standards); programmer welfare(40hours week)
48. Software Quality
In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions.
Whereas quality of conformance is concerned with implementation, quality of design measures how valid the design and requirements are in creating a worthwhile product[
Definition
One of the problems with Software Quality is that "everyone feels they understand it." In addition to the definition above by Dr. Scott Pressman, other software engineering experts have given several definitions.
A definition in Steve McConnell's Code Complete similarly divides software into two pieces: internal and external quality characteristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are those that do not.
Another definition by Dr. Tom DeMarco says "a product's quality is a function of how much it changes the world for the better." This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality.
Another definition, coined by Gerald Weinberg in Quality Software Management: Systems Thinking, is "Quality is value to some person ." This definition stresses that quality is inherently subjective - different people will experience the quality of the same software very differently. One strength of this definition is the questions it invites software teams to consider , such as "Who are the people we want to value our software?" and "What will be valuable to them?".
Source code quality
To a computer, there is no real concept of "well-written" source code. However, to a human, the way a program is written can have some important consequences for the human maintainers. Many source code programming style guides, which stress readability and some language-specific conventions are aimed at the maintenance of the software source code, which involves debugging and updating. Other issues also come into considering whether code is well written, such as the logical structuring of the code into manageable sections.
Readability
Ease of maintenance, testing, debugging, fixing, modification and portability
Low complexity
Low resource consumption: memory, CPU
Number of compilation or lint warnings
Methods to improve the quality: refactoring.
49. Software Quality Factors
A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program.
Some software quality factors are listed here:
Understandability is possessed by a software product if the purpose of the product is clear. This goes further than just a statement of purpose - all of the design and user documentation must be clearly written so that it is easily understandable. This is obviously subjective in that the user context must be taken into account, i.e. if the software product is to be used by software engineers it is not required to be understandable to the layman.
A software product possesses the characteristic completeness to the extent that all of its parts are present and each of its parts are fully developed. This means that if the code calls a sub- routine from an external library, the software package must provide reference to that library and all required parameters must be passed. All required input data must be available .
A software product possesses the characteristic conciseness to the extent that no excessive information is present. This is important where memory capacity is limited, and it is important to reduce lines of code to a minimum. It can be improved by replacing repeated functionality by one sub-routine or function which achieves that functionality. It also applies to documents.
A software product possesses the characteristic portability to the extent that it can be operated easily and well on multiple computer configurations. Portability can mean both between different hardware setups--such as running on a Mac as well as a PC--and between different operating systems--such as running on both Mac OS X and GNU/ Linux .
A software product possesses the characteristic consistency to the extent that it contains uniform notation, symbology and terminology within itself.
A software product possesses the characteristic maintainability to the extent that it facilitates updating to satisfy new requirements. Thus the software product which is maintainable should be well-documented, not complex, and should have spare capacity for memory usage and processor speed.
A software product possesses the characteristic testability to the extent that it facilitates the establishment of acceptance criteria and supports evaluation of its performance. Such a characteristic must be built-in during the design phase if the product is to be easily testable - a complex design leads to poor testability.
A software product possesses the characteristic usability to the extent that it is convenient and practicable to use. This is affected by such things as the human-computer interface. The component of the software which has most impact on this is the user interface (UI), which for best usability is usually graphical (i.e. a GUI).
A software product possesses the characteristic reliability to the extent that it can be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whichever conditions it finds itself - this is sometimes termed robustness.
A software product possesses Structuredness to the extent that it possesses a definite pattern of organisation in its constituent parts. A software product written in a block-structured language such as Pascal will satisfy this characteristic.
A software product possesses the characteristic efficiency to the extent that it fulfills its purpose without waste of resources. This means resources in the sense of memory utilisation and processor speed.
A software product possesses the characteristic security to the extent that it is able to protect data against unauthorized access and to withstand malicious interference with its operations. Besides presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies reliability in the face of malicious, intelligent and adaptive attackers.
58. Acceptance Testing
In engineering and its various subdisciplines, acceptance testing is black -box testing performed on a system (e.g. software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery. In some engineering subdisciplines, it is known as functional testing, black-box testing, release acceptance, QA testing, application testing, confidence testing, final testing, validation testing, usability testing, or factory acceptance testing.
In most environments, acceptance testing by the system provider is distinguished from acceptance testing by the customer (the user or client) prior to accepting transfer of ownership. In such environments, acceptance testing performed by the customer is known as beta testing, user acceptance testing (UAT), end user testing, site (acceptance) testing, or field (acceptance) testing.
59. Configuration Management.
-managing the products of system change (for different machines,offering diff. Funcktionality); is concerned with managing evolving software systems (system change=team activity,CM aims to control the costs and effort in making changes),involves the development and application of procedures.
CM standarts – CM should be based on a set of standarts that r applied within an organization and should define how items r identified,how changes r controlled and how new versions r managed.
Configuration management planning: all products may have to be managed –specifications,designs,programs,test data,user manuals.
CM planning: -starts during the early phases of the project-must define the doc-s or doc classes which are to be managed (Formal documents)-Docs which might be required for future
system maintenance should be identified and specified as managed docs.
CM plan: defines:1. types of docs to be managed and a doc naming scheme 2. who takes responsibility for the CM procedures and creation of baselines 3. policies for change control and version management 4. the CM records which must be maintained.
C.item identification
- Large projects typically produce 1000s of docs which must be identified
- Some of these docs must be maintained for the lifetime of the software
- Doc naming scheme should be defined so that related docs have related names.
- A hierarchical scheme with multi-level names is probably the most flexible approach.
The C. database.All CM info should be maintained in a configuration database.The CM database should preferably be linked to the software being managed.
Change management software systems=subject to continual change requests from users/developers/market forces; is concerned with keeping these changes` managing and ensuring that they r implemented in the most cost-effective way.
Change request form-part of the CM planning process; records change required (suggestor,reason and urgency of change);records change avaluation, impact analysis,change cost and recom-s.
Change tracking tools -major problem in CM, which keeps track the status ofeach change request and automatically ensure that change requests are sent to the right people at the right time; Integrated with E-mail systems allowing electronic change request distribution.
Change control board : changes should be reviewed by an external group who decide whether or not they are costeffective from a strategic and organizational viewpoint rather than a technical viewpoint ;should be independent of project responsible for system.;may include representatives from client and contractor staff.
Release management. -Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes- must incorporate new system functionality-release planning is concerned with to issue a system verison as a release.
System releases not just a set of executable programs,may include configuration,data files, inst . program,electronic+paper documentation,packaging and publicity.
Release problems: customer may not want a new release,RM must not assume that all previous releases r accepted .All files required for a release should be re-created.
Release creation: 1. involves collecting all files+documentation required; 2.Configuration descriptions have to be written different hardware and installation scripts have to be written for;3.The specific release must be documented to record exactly what files were used to create it.This allows it to be re-created if necessary.
System Building -the process of compiling and linking software components into an executable system.
-Different systems are built from different combinations of components
- Invariably supported by automated tools that are driven by ‘build scripts’
CASE tools for configuration management
- CM processes are standardised and involve applying pre-defined procedures
- Large amounts of data must be managed
- CASE tool support for CM is therefore essential
- Mature CASE tools to support configuration management are available ranging from standalone tools to integrated CM workbenches
Manage Change Requests- The purpose of a standard, documented change control process is to ensure that changes in a project are made in a consistent manner and the appropriate stakeholders are informed of the state of the product, changes to it, and impact of these
changes on the cost and schedule.
Tool Support. The Rational Suite of software development tools supports the configuration and change management workflow with the following tools:
• Rational ClearCase assists with the configuration management portion.
• Rational ClearQuest assists with the change request management and status and measurement portions.

.DOC Laadi alla originaalfail 18 lk · .doc · 16 allalaadimist

100 punkti Autor soovib selle materjali allalaadimise eest saada 100 punkti.

~ 18 lehte Lehekülgede arv dokumendis

2015-04-08 Kuupäev, millal dokument üles laeti

16 laadimist Kokku alla laetud

0 arvamust Teiste kasutajate poolt lisatud kommentaarid

keeksirull Õppematerjali autor

process soft model object development mana class require program Tarkvara

Sarnased õppematerjalid

docx

Tarkvaratehnika

Tarkvaratehnika 1. Loeng Kvaliteetse tarkvara atribuudid: 1. Teostab ettenähtud funktsionaalsust 2. Hooldatav Tarkvara peab arenema, et vastata muutuvatele vajadustele. 3. Usaldusväärne Töökindlus ja turvalisus. 4. Vastuvõetav Kasutajad on aktsepteerinud selle. Tarkvara on neile arusaadav, kasutatav ja ühilduv teiste süsteemidega. Mis on tarkvaratehnika? Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara, mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähenemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele,

Tarkvaratehnika

doc

IT arhitektuur

1.The Conceptual Architecture identifies the high-level components of the system, and the relationships among them. Its purpose is to direct attention at an appropriate decomposition other system without delving into details. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and users. Logical Architecture In Logical Architecture, the externally visible properties of the components are made precise and unambiguous through well-defined interfaces and component specifications, and key architectural mechanisms are detailed. The Logical Architecture provides a detailed "blueprint" from which component developers and component users can work in relative independence. Logical Architecture. Model System Behavior Execution Architecture An Execution Architecture is created for distributed or concurrent systems. The process view shows the mapping of components onto the processes of the physical system, with atte

It arhitektuur

pdf

IT Strateegia IT Ettevõttele

Table of Contents 1. Background ..............................................................................................................................2 2. Business Plan............................................................................................................................2 2.1. Mission..............................................................................................................................2 2.2. Values ...............................................................................................................................2 2.3. SWOT Analysis of the Organization ................................................................................2 2.4. Opportunities ....................................................................................................................3 2.5. Primary Processes ........................................................................................

Informaatika

doc

Introduction of SCM

INTRODUCTION OF SUPPLY CHAIN MANAGEMENT (SCM) A supply chain is a network of facilities and distribution options that performs the functions of procurement of materials, transformation of these materials into intermediate and finished products, and the distribution of these finished products to customers. Supply chains exist in both service and manufacturing organizations, although the complexity of the chain may vary greatly from industry to industry and firm to firm. Supply chain management is typically viewed to lie between fully vertically integrated firms, where the entire material flow is owned by a single firm and those where each channel member operates independently. Therefore coordination between the various players in the chain is key in its effective management. Cooper and Ellram [1993] compare supply chain management to a well-balanced and well-practiced relay team. Such a team is more competitive when each player knows how to

Kategoriseerimata

Integration of Lean Con-and Building Information Modelling

109

pdf

Integration of Lean Con. and Building Information Modelling

Ergo Pikas Integration of Lean Construction and Building Information Modelling DISSERTATION Tallinn 2010 2 UNIVERSITY OF APPLIED SCIENCES Author: Ergo Pikas- Civil Engineering student, Faculty of Construction, Tallinn University of Applied Sciences Supervisor: Rafael Sacks- Associate Professor, Faculty of Civil and Env. Engineering, Technion Israel Institute of Technology Consultant: Roode Liias- Professor and Dean, Faculty of Civil Engineering, Tallinn University of Technology Title: Integration of Lean Construction and Building Information Modelling Archived: University of Applied Sciences, Faculty of Construction ABSTRACT This research can be divided into two. The first part investigates the current state of the construction industry, while the second part looks at new emerging busin

Ehitusjuhtimine

txt

Erialane inglise keele konspekt

Erialane inglisekeel 2 semester. Software engineering Tarkvara tehnika. Sub.discliplines of software engineering. 1. Software requirements 2. Software design 3. Software develompment 4. Software testing 5. Software maintenance 6. Software configuration managment 7. Software engineering managment 8. Software development process 9. Software qengineering tools 10. Software quality Ex 1 1. analysing and defining the problem to be solved. 2. Desiging the program. 3. Coding. 4. Testing. 5. Training the users. 6. Dockumenting. 7. Obtaining feedback from user UML- united modeling language Algoritm- eeskiri mis tleb kuidas seda prorgammi kirjutada. Teine tund. protsessori- keskmine keel on assemble languages. Interpreted languages- tlgendamine. Declarated languages- kirjeldatakse programmi omadusi. Object- oriented class- based languages 1) multiple dispatch 2) single dispatch. Scripting languages- ja

Arvutiõpetus

140

pdf

Thesis Kivimaa August 2022

Thesis “How is it possible to calculate IT security effectiveness?” Kristjan Kivimaa August 2022 1 Abstract In IT Security world, there is lack of available, reliable systems for measuring security levels/posture. They lack the range of quantitative measurements and easy and fast deployment, and potentially affects companies of all sizes. Readily available security standards provide qualitative security levels, but not quantitative results – that would be easily comparable. This deficiency makes it hard for companies to evaluate their security posture accurately. Absence of security metrics makes it complicated for customers to select the appropriate measures for particular security level needed. The research question for this research project is – “How is it possible to calculate IT security effectiveness?”. The aim of this research is to use this reference m

Infotehnoloogia

pdf

Tarkvaratehnika 3 variant

programming(all production code is pair programmed), continuous learning(take time to improve team's skills), retrospective(look back and improve) 3 вещи в рукводстве проекта(?)3 фактора при разработке квалитетного ПО Too välja 3 kvaliteetse tarkvarasüsteemi atribuuti (üks kliendi, üks arendaja, üks äri vaatest) ning selgita, kuidas nad mõjutavad arhitektuurilise kavandamise valikut. Hooldatavus: Tarkvara peab arenema, et vastata muutuvatele vajadustele; Usaldusväärsus: Tarkvara peab olema töökindel; Efektiivsus: Tarkvara ei tohi raisata süsteemi ressursse; Vastuvõetavus: Tarkvara peab olema aktsepteeritud kasutajate poolt, kelle jaoks ta on loodud. See tähendab, et tarkvara peab olema arusaadav, kasutatav ja ühilduv teiste süsteemidega

Tarkvaratehnika

Rohkem sarnaseid