Flashcards in Final Deck (82):
Refers to the difficulty of writing useful and efficient computer programs in the required time.
Symptoms of a software crisis
- Over-budget projects
- Late projects
- Inefficient projects
- Low quality software
- Software that did not meet requirements
- Unmanageable projects
- Difficult to maintain code
- Never delivered software
IEEE definition of software engineering
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
Systematic - done or acting to a fixed plan; methodical
Disciplined - showing a controlled form of behavior or way of working
Quantifiable - capable of being measured
Development - the approach to making the software
Operation - the approach to how the software works
Maintenance - the approach to "fixing" the software
The four P's of software engineering
People - project stakeholders
Product - the software being produced, and associated documentation
Project - the activities performed to create the product
Process - the framework within which the team carries out the activities necessary to build the project
Software development lifecycle
- Requirements gathering and analysis
Determine the problem being solved
- Identity the system that is needed
- Identify high-level functionality
- Identity how the system fits into the client's ecosystem?
Find out and record exactly what the software should do
- Find out what the software should not do
- Determine all stakeholders
- Produce requirements documentation
- Do an initial analysis model
- Review requirements with stakeholders to ensure correctness and completeness
Determine the architecture of the application
Determine algorithms and data structures used to implement the system and architecture
- Unit and integration testing
Validate that the requirements are satisfied by the software
- Verification and validation (V&V)
- Unit testing
- Integration testing
- Regression testing
- Acceptance testing
Delivery to client
Fix bugs, update software, add/subtract features, etc.
Why use life-cycle models
- Helps to organize, plan, staff, budget, and schedule
- Outlines documents and deliverables
- Helps set milestones
- Describes what tools and staffing are needed
- Helps measure cost, quality and productivity per process
- Helps the organization improve the quality of the process
Describe the waterfall model
- Requirements specification
- Documentation for each phase is the input for the next phase
- Each phase must be completed before the next phase
- Each deliverable becomes a milestone
- Document driven
- Repeatedly execute the full development cycle on small chunks
- Each increment releases a useful feature
- Requires a well-partitioned design
- Drawback: you may no know if the entire system works until the end
- Repeatedly execute the full development cycle
- Add depth to the system on each round
- User has a working system from the beginning
- Feature-rich releases come later
- Iterative and incremental
- Agile Manifesto removes the focus from strict documentation to faster releases
- Small, close-knit teams
- Regular, frequent, disciplined customer requirements meetings
- A code-centric approach with documentation as-needed
- Customer representatives working within the team
- The use of user stores for requirements
- Pair programming
- Continual unit testing and acceptance testing
- An agile model
- Project management based approach
- Get the user requirements in the form of user stories but not all at once
- Estimate the effort for each user story
- Keep a backlog for user stories
- For each iteration only attempt what can be done in one iteration
- Iterations are a maximum of one month
Describe Extreme Programming (XP)
- Incremental planning: User Stories on Story Cards, prioritized for a release
- Small releases: the smallest possible set of functionality that provides value is developed first
- Simple design: Only design what you're currently working on and do no more
- Test-driven development: write automated unit tests before the implementation of the functionality
- Refactoring: make code simple and refactor it often
- Pair programming: developers work in teams of two, checking each other's work and providing support
- Collective ownership: developer pairs work on all areas of the system to prevent "islands of expertise"
- Continuous integration: as soon as a task is complete, it is integrated into the entire system; requires all unit tests to pass for the entire system
- Sustainable pace: overtime is not a common practice because it can reduce code quality
- On-site customer: the customer should be available to the XP team at all times; the customer representative becomes a member of the development team
- Coding standard: the team agrees to follow a specific set of rules regarding development style throughout the project; XP advocates self-documenting code as much as possible
- System metaphor: the metaphor is a story that every stakeholder can tell about how the system works; this extends to naming classes and methods in a way that describes their intended used and relates to the issue of self-documenting code
Rational Unified Process (RUP)
- Designed to sit between heavyweight and agile methods
- Use-case driven
- Iterative and incremental
- Inception: develop a business case for the system
- Elaboration: refine the initial requirements, refine the architecture, and monitor the risks and refine their priorities
- Construction: programming and implementation with integral testing activities
- Transition: move the system from the development environment to the real environment
How to pick a life-cycle model
- Inertia: we've always used this method (typically not a good mindset)
- Market hype: everyone is using method x, so we should too
- Size/complexity analysis: agile methods may not work for large projects
- Best practice analysis
Capability Maturity Model Integration (CMMI)
Rate an organization's process maturity
Consists of 5 levels:
0 - Incomplete
1 - Initial
2 - Managed
3 - Defined
4 - Quantitatively Managed
5 - Optimizing
- You basically just do it
- Undefined/Ad Hoc
- Depends on team members
Usually over budget and past due
Prediction is possible through quantitative means
- Standardized process
- All projects are consistent in process
- Quantitatively predictable
- Process measured
- Metrics available for the process
- Improvement process
- Process metrics lead to continuous improvement
A description of a service that the system is expected to provide and the constraints under which it must operate.
Sub-phases of the requirements proess
- Business process analysis
- User interface
- Create software model
- Reduce ambiguities
- Precisely state requirements
- Recording he specification
- Include functional and non-functional requirements
- Ensure you have the right requirements
- Ensure you have the requirements right
- Describe an interaction between the software and a user, another system, a database, etc.
- There is typically a set of inputs, an operation, or a set of outputs
- Do not specify software functionality
- Specify restrictions on some operation or thing
- Must be specific, quantifiable, and testable
Sources of requirements
- Existing systems
- Policy and procedure manuals
- Forms used in existing systems
- System manuals
- Issue logs
- Requirement Reports
- Problem Identification and Definition Document (PID)
- Top-Level Requirements (TLR) Document
- Software Requirements Specification (SRS)
- Use Cases and Scenarios
- User Stories and Scenarios
- Analysis Models
- Questions are pre-determined
- Adapt the questions based on responses
- Interview has no pre-determined questions, only a task to perform
- Give the user a common problem to step through
- Ask questions while the user describes the steps
- The goal is to form a model of the user's thought process
- There are no predefined questions or agenda
- Open discussion about what the client/user wants from the software
- "Walking around"
- Watch what users are doing, and how they are doing it
- Good for workflow analysis (capturing who does what and when)
- Good when replacing existing systems of automating manual tasks
- Look at existing business documents to glean business processes
- Good when replacing paper processes
- Create a prototype (an initial version of the software available early in the development process)
- Often a throw-away (it is scrapped after gathering the requirements)
- Helps to verify the requirements
- Effective for developing user interfaces
- Can reveal inconsistencies in written requirements
Problem Identification and Definition Document (PID)
- Very high-level document
- Identifies the business value of the system
- Lists the high-level functionalities
1.) Name the project
2.) Identify the project sponsor(s)
3.) Identify the business need
4.) Identify user roles and high level functionalities
5.) Identify the expected value (feasibility analysis)
6.) Identify an special issues
7.) Glossary of Terms
8.) Priority List
Software Requirements Specification (SRS)
- IEEE Standard for software specifications
- Contains an overall description and specific requirements of the software
The structure or structures of a system, which comprise software components, the externally visible requirements of those components, and the relationships among them.
Used to separate the areas of concern in an application.
Segregates the system into two applications, where the client makes requests to the server.
Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.
Partitions the concerns of the application into stacked groups (layers).
Segregates the functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Draw an architectural analysis model
Draw use case diagrams
Draw a data model using a class diagrm
Draw a functional model (high and low level) using a sequence diagram
Draw a behavioral model using state-machine diagrams
Draw a web application archetype
Draw a mobile application archetype
Draw a rich client application archetype
The degree to which software components are interconnected
The degree to which elements of a group belong together.
The interface between the units is a parameter list and all parameters are needed.
The interface between the units is a parameter, which is some data structure containing fields but not all fields are needed.
The interface between the units is data (e.g., flags and switches) that influences the internal logic of the unit.
The elements of the program unit are grouped because they all contribute to a single, well-defined task.
The elements of the program unit are grouped because the output of one part is the input into another part.
The elements of the program unit are grouped together because they operate on the same data. It may be possible that the parts are performing more than one function.
The elements of the program unit are grouped together because they always follow a certain sequence of execution.
Single Responsibility Principle (SRP)
A class should have one, and only one, reason to change.
Open Closed Principle (OCP)
You should be able to extend a class' behavior without modifying it.
Liskov Substitution Principle (LSP)
Derived classes must be substitutable for their base classes.
Interface Segregation Principle (ISP)
Make fine grained interfaces that are client specific.
Dependency Inversion Principle (DIP)
Depend on abstractions, not on concretions.
Creational design pattern in which there is exactly one instance of a class.
Structural design pattern that solves the problem of using a different protocol/interface between interacting components.
- Write the application against abstract version of the external class.
- Introduce a subclass that aggregates the external class
- The client interacts with the Adapter, who rewrites it for the required class.
A behavioral design pattern that essentially allows the definition of a family of algorithms, which are all interchangeable depending upon the client that uses them.
The process used by developers to identify and fix defects in the program units.
Setting up the environment, making sure all preconditions are met, selecting the input data, and determining the expected result.
Applying the input data to the unit.
Comparing the actual result to the expected result.
Test class using MSTest
public class ABankAccount
ShouldSetBalanceAndAnnualInterestRateWhenConstructed ( )
// Arrange, Act
var sut = new BankAccount (100.0m, 0.1m);
Assert.AreEqual (100.0m, sut.Balance);
Assert.AreEqual (0.1m, sut.AnnualInterestRate);
Divides input values into equivalent groups; used to limit the number of test cases to something "reasonable."
Ensures all statements in the unit are executed at least once by at least one test case.
Ensures all branches in the unit are executed at lease once by at least one test case.
Ensures that all path combinations in the unit are executed.
Describe the process of conducting a formal code review
- The author of the unit ensures that the unit is ready for review
- Before the meeting, each reviewer carefully review the code.
- The author gives an overview of the logic, computation, and dependencies used in the code.
- At the end of the meeting, the record-keeper produces a summary of the meeting.
- The CRs are independently validated by the moderator or another person designated for that purpose
- The review process is complete.