¡Escribe tu texto aquí!Efficiency :Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc.Acceptability:Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use.AttributesOf GoodSoftware:Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.Costsofsoftwareengineering:Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.Plan-Driven and Agile (Active) Processes. Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.In practice, most practical processes include elements of both plan-driven and agile approaches.There are no right or wrong software processes.The waterfall model:Plan-driven model. Separate and distinct phases of specification and development. Plan-driven, This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.Incremental development:Specification, development and validation are interleaved. May be plan-driven or agile. This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.WATERFALLMOD:RequierementsDefinition>System&SoftwareDesign> Implementation&UnitTesting>Integration&SystemTesting>Operaion&Maintenance<<  Advantages: Is divided in phases and its planned in advance, is good for large systems that doesn’t not require modifications during the process and all the process is visible.Disadvantages:Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.Increm.Dev:OutlineDescription->((Specification><InitialVersion)><(Development><IntermediateVersions)><(Validation>FinalVersion))

Advantages: The cost of accommodating changing customer requirements is reduced.The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model.It is easier to get customer feedback on the development work that has been done.Customers can comment on demonstrations of the software and see how much has been implemented.More rapid delivery and deployment of useful software to the customer is possible.Customers are able to use and gain value from the software earlier than is possible with a waterfall process. Disadvantages: The process is not visible.Managers need regular deliverables to measure progress. If systems are developed quickly, it is notcost-effective to produce documents that reflect every version of the system.System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Throw-Away Prototypes:Prototypes should be discarded after development as they are not a good basis for a production system:It may be impossible to tune the system to meet non-functional requirements;Prototypes are normally undocumented;The prototype structure is usually degraded through rapid change;The prototype probably will not meet normal organizational quality standards.Incremental Delivery:Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.User requirements are prioritized and the highest priority requirements are included in early increments.Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.Refactoring.:Replacing the in-line code for Methods, to making the code as simple as possible to deliver the documentation because it must has to be every two weeks, also renaming the methods and all the attributes of the class and reorganize the class hierarchy Scaling out: Is concerned with using agile methods for developing large, software systems that cannot be developed by small team.Scaling up: Is concerned with how agile methods can be introduced across a large organization with many years of software experience.TypesofRequirementEngineering:User requirements:Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.System requirements:A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.Functional requirements:Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.May state what the system should not do.Non-functional requirements:Often apply to the system as a whole rather than individual features or services.Domain requirements:Constraints on the system from the domain of operation.RequirementAbstractionDavis’s view:“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”For the Non-functional Requirements discuss the following: Properties and Constraints Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Showtheblock diagramofdifferenttypes Non-functionReq.->((ProductReq->UsabilityRq,(EfficiencyReq->Performance&SpaceReq),DependabiltyRq,SecurityRq),(OrganizationalReq->EnvironmentalRq,OperationalRq,DevelopmentRq.),(ExternalReq.->RegulatoryReq,EthicalReq,(LegislativeReq->Accountint&safetyReq))Typeindetails:Product requirements:Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organisational requirements:Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirements:Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.Examplesofeachtypeinrealcase:Product requirement:The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.Organizational_requirement:Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.External_requirement:The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.