CSC 395 - Chapters 1, 2, 3, 4, 5 Flashcards
Describe the essentials of good software
- Acceptability – software is acceptable to the users for which it was designed. It must be understandable, usable and compatible with other systems they use
- Dependability and security – dependable software should not cause physical or economic damage in the event of system failure. The software has to be secure so that malicious users cannot access or damage the system
- Efficiency – software should not waste system resources such as memory and processor cycles. Efficiency includes responsiveness, processing time, resource utilization etc.
- Maintainability – Software should be written so that it can evolve to meet the changing needs of the customer.
Briefly describe the software process activities
- Software Specification – where customers and engineers define the software that is to be produced & the constraints on its operation and development. Mistakes made at this level often lead to further mistakes in the system.
- Software Development – where the software is designed and programmed.
- Software Validation – where the software is checked to ensure that it does what the software specification says and is what the customer required.
- Software Evolution – where the software is modified to reflect changing customer and market requirements.
Describe the Waterfall Model
Takes the software process activities and represents them as separate process phases of requirements definition, system and software design, implementation and unit testing, integration and system testing, operation and maintenance. It is a plan-driven approach.
Problems:
• Distinct changes make it difficult to accommodate change because a phase has to be completed before moving to the next phase
• Mostly used for large projects
Describe the Spiral Model
Keep repeatedly running through the steps of design, code, testing and integration – each step building on what was done before
Describe Incremental Delivery
Incremental delivery interleaves the software process activities and can be either a plan driven or agile approach. The system is developed as a series of versions (increments) where each version adds part of the required functionality to the previous version. User requirements are prioritized where the highest priority is developed first.
Benefits:
• There is a lower risk of overall project failure
• The cost for requirement changes is reduced
• Customer feedback can be given for each version which establishes trust
• Early delivery and deployment of useful software is possible
Problems:
• Many organizations require a complete system specification as part of the system development contract but it is not cost effective to produce documents that reflect every version of the system
• System structure tends to degrade as new increments are added
Describe the Agile Manifesto
It is the philosophy behind agile methods. It values:
•Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Describe test-first development
Used in Extreme Programming
Tests that are written before the code – this requires there to be a clear relationship between system requirements and the code implementing the requirements
The testing is automated and is central to the development process – the development process cannot continue until all tests are successfully executed. All previous and new tests are run when new functionality is added.
Problems with test-first development:
• Programmers prefer programming over testing
• Some tests can be difficult to write incrementally
• It’s difficult to judge the completeness of tests
Describe the Scrum phases and sprint cycle
Scrum is an agile method centered around a series of sprints. Scrum provides a framework for organizing agile projects.
• Outline planning phase – establishes the general objectives and designs the software architecture.
• Sprint cycle – each cycle develops an increment of the system
¬ Each sprint cycle lasts 2 to 4 weeks and the starting point is at the product backlog (which is a list of items to be worked on). A selection phase involves the project team that works with the customer to select the work from the backlog to be developed during the sprint. The team decides who is going to work on what and all communication between the team goes through the scrum master (who acts as a project manager). A sprint is never extended to finish work, anything unfinished goes back to the backlog. During each sprint cycle there are scrums, which are daily meetings to review progress and reprioritize if necessary. At the end of a sprint, the work done is reviewed and presented.
• Project closure phase – wraps up the project. It completes the required documentation and assesses the lessons learned from the project.
Explain the difference between user requirements and system requirements
User requirements are written statements and diagrams of the services the system provides. They include the operational constraints and are written for customers.
System requirements are written in a structured document and contains detailed descriptions of the systems functions, services and operational constraints. They define what should be implemented and may be part of a contract between the client and the contractor.
Explain the difference between functional requirements and non-functional requirements
The functional requirements are the services the system should provide, how the system should react to particular inputs, how the system should behave in particular situations and may state what the the system should not do.
The non-functional requirements are the constraints on the services or functions offered, defines system properties and constraints and may specify the particular IDE, programming language or development method. If the non-functional requirements are not met, the system may be useless. There are three classifications for non-functional requirements: product requirements, organization requirements and external requirements.
Briefly describe the four elements common in the requirements engineering process
- Requirements elicitation – working with customers to find out about the application domain, the services the system should provide and the systems operational constraints.
- Requirements specification – formalizes the user and system requirements. It should be part of the system development contract and should state what the system should do. (Usually a document)
- Requirements validation – demonstrating the requirements define the system that the customer really wants. Validations catches errors before development.
- Requirements change management – decides if requirement changes should be accepted. It will go through a problem analysis and change specification, the change analysis and costing and finally the change implementation.
Describe the four system perspectives
- External – model the context or environment of the system
- Interaction – model the interactions between a system and its environment; model the interactions between the components of a system
- Structural – model the organization of a system; model the structure of the data processed by the system
- Behavioral – model the dynamic behavior of the system and how it responds to events
Describe the five main types of UML diagrams
- Activity Diagrams – A behavioral diagram that shows the activities involved in a process or in data processing. The activities and the flow of control from one to another are shown and indicated by arrows. The start of a process is represented by a filled circle, the end by a filled circle inside another circle. Solid bars throughout the diagram indicate activity coordination.
- Case Diagrams – A behavioral diagram that shows the interactions between a system and its environment. Each use case represents a discrete task that involves external interaction with a system. An actor (indicated by a stick figure) can be a person or a system.
- Sequence Diagrams – A behavioral diagram that shows the interactions between actors/objects and the system and between system components. It shows the sequence of interactions that take place during a particular use case. The objects and actors involved are listed along the top of the diagram with a dotted line drawn vertically from these.
- Class Diagrams – A structural diagram that shows the object classes in a system and the associations between these classes. An association is a link between classes that have some kind of relationship. They have three sections, one for the class name, one for the attributes and one for the operations.
- State Diagrams – A behavioral diagram that shows how the system reacts to internal and external events. They do not show the flow of data within the system but may include additional information on the computations carried out.
