Soft Dev Midterm Study Guide

<<extends>>

- <<extends>> relationships model exceptional or seldom invoked cases - the direction of an <<extends>> relationship is to the extended use case

4 C's of Requirements

Complete, Consistent, Correct, Clear

cd

Change Directories - ie. move to another directory

Process Framework

Set of guidelines and tools that attempt to facilitate a process

nonfunctional requirements

user visible aspects of the system not directly related to functional behavior

use cases

general sequences of events that describe all the possible actions between an actor and the system for a given piece of functionality

requirements elicitation

helps the customer to define what is required: what is to be accomplished, how the system will fit into the needs of the business, and how the system will be used on a day-to-day basis - definition of the system in terms understood by the customer

actors

include roles such as end users, other computers the system needs to deal with

Project description

interactive output display of the schedule

incremental model

model of organizational decision making in which major solutions arise through a series of smaller decisions

team software process

provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software products that range in size from small projects of several thousand lines of code to very large projects greater than half a million lines of code - build self-directed teams that plan track their work ,establish goals, and own their processes and plans - show managers how to coach and motivate their teams and how to help them sustain peak performance - accelerate software process improvement by making CMM Level 5 behavior normal and expected - provide improvement guidance to high-maturity organizations - facilitate university teaching of industrial-grade team skills

requirements analysis

refining and modifying the gathered requirements - technical specification of the system in terms understood by the developer

mv

rename file mv copy.txt clone.txt

sequence diagrams

represent the behavior of a system as messages ("interactions") between different objects - the source of an arrow indicates the activation which sent the message - horizontal dashed arrow indicate data flow

class diagrams

represent the structure of the system

<<includes>>

- <<includes>> relationship represents common functionality needed in more than one use case - <<includes>> behavior is factored out for reuse, not because it is an exception - the direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship)

GIT

- A distributed VC system - Get your own repo - Can do all VC operations locally now - You need to clone a repo - Local operations: update/commit, tag/branch, log/diff - Remote operations: - Pull: Get all changesets from origin repo - Push: Send your changesets to origin - Still has origin repo to communicate between team members - pull can be divided into fetch+merge

UML Core Conventions

- All UML Diagrams denote graphs of nodes and edges - Nodes are entities drawn as rectangles or ovals - Rectangles denote classes or instances - Ovals denote functions - Names of Classes are not underlined - Names of Instances are underlined - An edge between two nodes denotes a relationship between the corresponding entities

bash scripting

- Bash scripts tell the Bash shell what it should do - A Bash script is a plain text file which contains a series of commands. - Before executing a script it must have the execute permission set (chmod 755).

spiral model

- Boehm's spiral model is an activity-centered life cycle model that was devised to address the source of weaknesses in the waterfall model, in particular, to accommodate infrequent change during the software development. It is based on the same activities as the waterfall model; however, it adds several activities such as risk management, reuse, and prototyping to each activity. These extended activities are called cycles or rounds. - The spiral model focuses on addressing risks incrementally, in order of priority. Each round is composed of four phases. During the first phase, developers explore alternatives, define constraints, and identify objectives. During the second phase, developers manage risks associated with the solutions defined during the first phase. During the third phase, developers realize and validate a prototype or the part of the system associated with the risks addressed in this round. The fourth phase focuses on planning the next round based on the results of the current round. The last phase of the round is usually conducted as review involving the project participants, including developers, clients, and users. - Each round follows the waterfall model and includes the following activities: (1) determine objectives, (2) specify constraints, (3) generate alternatives, (4) identify risks, (5) resolve risks, (6) develop and verify next-level product, (7) plan

centralized VC

- Centralized version control systems are based on the idea that there is a single "central" copy of your project somewhere, and programmers will commit their changes to this central copy.

Analysis object model

- Class diagrams - High-level - User perspective - Fewer details: Database details, network details, etc. should not be part of this - Most classes will map to classes in the software

Why is software engineering difficult?

- Complexity and change: Useful software systems are complex. To remain useful they need to evolve with the end users' need and the target environment. - Software engineers do not have infinite resources and are constrained by budget and deadlines.

Process of software development

- During requirements elicitation, the client and developers define the purpose of the system. The result of this activity is a description of the system in terms of actors and use cases. - During analysis, developers aim to produce a model of the system that is correct, complete, consistent, and unambiguous. Developers transform the use cases produced during requirements elicitation into an object model that completely describes the system. The result of analysis is a system model annotated with attributes, operations, and associations. - During system design, developers define the design goals of the project and decompose the system into smaller subsystems that can be realized by individual teams. Developers also select strategies for building the system, such as the hardware/software platform on which the system will run, the persistent data management strategy, the global control flow, the access control policy, and the handling of boundary conditions. The result of system design is a clear description of each of these strategies, a subsystem decomposition, and a deployment diagram representing the hardware/software mapping of the system. - During object design, developers define solution domain objects to bridge the gap between the analysis model and the hardware/software platform defined during system design. The result of the object design activity is a detailed object model annotated with constraints and precise descriptions for each element. - During implementation, developers translate the solution domain model into source code. This includes implementing the attributes and methods of each object and integrating all the objects such that they function as a single system. The implementation activity spans the gap between the detailed object design model and a complete set of source code files that can be compiled. - During testing, developers find differences between the system and its models by executing the system (or parts of it) with sample input data sets. During unit testing, developers compare the object design model with each object and subsystem. During integration testing, combinations of subsystems are integrated together and compared with the system design model. During system testing, typical and exception cases are run through the system and compared with the requirements model. The planning of test phases occurs in parallel to the other development activities: System tests are planned during requirements elicitation and analysis, integration tests are planned during system design, and unit tests are planned during object design. - The process of developing software can also be viewed as a complex system with inputs, outputs, activities, and resources. A general model of the software development process is called a software life cycle.

HTTP

- HTTP stands for Hypertext Transfer Protocol - A browser is an HTTP client because it sends requests to an HTTP server (Web server), which then sends responses back to the client. - HTTP is used to transmit resources, not just files. A resource is some chunk of information that can be identified by a URL - An HTTP client sends an HTTP request to a server in the form of a request message - HTTP: the set of commands understood by a web server and sent from a browser - GET request: Asks a server for a page or data. If the request has parameters, they are sent in the URL as a query string. - POST request: Submits data to a web server and retrieves the server's response. If the request has parameters, they are embedded in the request's HTTP packet, not the URL.

HTML

- Hypertext Markup Language - Can modify pretty much anything about the look and organization of your page - Can link to other resources on your computer or anywhere else on the web - <a href="LINK"> description </a> - All dynamic web pages use Common Gateway Interface (CGI) -Submitting web form calls executable -Executable produces HTML

inheritance

- In an inheritance relationship, the subclass refines the superclass by defining new attributes and operations.

generalization-specialization

- Inheritance - Given specific information, identify common features (generalization) - Reduce redundancies - Inheritance is used during Analysis and Object design

Project Roles

- Lead programmer: framework, components, coding style. Doesn't mean the only programmer. Everyone must program, lead programmer decides on the overall design and coding standards. - UI/UX design: User Interface and User experience. Make mock UI designs and user-friendly navigation. (Kyle) - Data modeler: Database, data files, server-client structure, data structures. (Joshua) - Team manager: sprint planning, and time accounting for the team. - Client liaison: Communications, demos, and negotiations with client, what was done and planned to handle client's requirements (role can be combined with manager) (Kyle) - Documentation lead: Setup documentation conventions for code and project, then delegate work onto teammates. Manage presentations, reports, and licensing documentation. Everyone must add documentation. (Mark) - Testing lead: Setup testing framework and conventions. Use continuous integration to test at each commit/push. Everyone must do their own testing. (Mark and Joshua)

What is software engineering?

- Software engineering is a modeling activity. Software engineers deal with complexity through modeling, by focusing at any one time on only the relevant details and ignoring everything else. - Software engineering is a problem-solving activity. Models are used to search for an acceptable solution. This search is driven by experimentation. - Software engineering is a knowledge acquisition activity. In modeling the application and solution domain, software engineers collect data, organize it into information, and formalize it into knowledge. - Software engineering is a rationale-driven activity. When acquiring knowledge and making decisions about the system or its application domain, software engineers also need to capture the context in which decisions were made and the rationale behind these decisions. -Software engineering is the study of and practice of engineering to build, design, develop, maintain, and retire software.

V-model

- The V-model is a variation of the waterfall model that makes explicit the dependency between development activities and verification activities. The difference between the waterfall model and the V-model is that the latter depicts the level of abstraction. All activities from requirements to implementation focus on building an increasingly detailed representation of the system, whereas all activities from implementation to operation focus on validating the system. The horizontal object flow denotes the information flow between activities at the same abstraction level. - Higher levels of abstractions of the V-model deal with the requirements in terms of elicitation and operation. The middle level of the V-model focuses on mapping the problem into a software architecture. The lower level of the V-model focuses on details such as the assembly of software components and the coding of new ones.

Sequence Diagrams: General Rules

- The first column should correspond to the actor who initiated the use case. - The second column should be a boundary object (that the actor used to initiate the use case). - The third column should be control object that manages the rest of the use case. - Control objects are created by boundary objects initiating use cases. - Boundary objects are created by control objects. - Entity objects are accessed by control and boundary objects. - Entity objects never access boundary or control objects; this makes it easier to share entity objects across use cases.

distributed VC

- These systems do not necessarily rely on a central server to store all the versions of a project's files. Instead, every developer "clones" a copy of a repository and has the full history of the project on their own hard drive. This copy has all of the metadata of the original.

MVC pattern

- Time object keeps track of time (Model) - LCDDisplay object displays the tracked time (View) - TimeControl object manages changes to time (Controller)

Advantages of using Version Control

- Track changes, keep logs of past development - Automatic backups/safety net - Concurrent versions: XP vs. Win8 - Allows teamwork

Communication in Software Engineering

- Two types of communication: planned communication and unplanned communication - Planned communication events are scheduled points in time during which participants exchange information on a specific topic or review a work product. Typical planned communication events include: problem presentation, client reviews, project reviews, peer reviews, status reviews, brainstorming, releases, postmortem reviews. - The focus of problem presentation is the presentation of the Problem Statement that describes the problem, the application domain, and the desired functionality of the system. - The goal of client reviews is for the client to assess the progress of the development and for the developers to confirm or change the requirements of the system. - The goals of a project review are for the project manager to assess status and for teams to review subsystem interfaces. - The objective of code inspections and walkthroughs is to increase the quality of a subsystem through peer review. During walkthrough, a developer presents to the other members of her team line-by-line the code she has written. During inspections, the members of the team focus on the compliance of the code with a predefined list of criteria. - Unlike client and project reviews that focus on the system, status reviews focus on tasks. Status reviews are primarily conducted in a team and occasionally conducted in a project. The objective of status reviews is to detect deviations from the task plan and to correct them. - The goal of the brainstorming process is to generate a large number of solutions to a problem, regardless of their merit, then evaluate them. - The goal of a release is to make a work product available to other project participants, often replacing an older version of the artifact. - Postmortem reviews focus on extracting lessons from the development team once the software is delivered. - A project should be prepared to deal with unexpected situations, often under pressure. We call the communication resulting from such crises unplanned communication events. They include: request for clarification, request for changes, and issue resolution - Requests for clarification represent the bulk of the communication among developers, clients, and users. - During a request for change, a participant reports a problem and, in some cases, proposes solutions. - An issue base can serve as a communication mechanism for supporting problem tracking and issue resolution. - A communication mechanism refers to a tool or procedure that can be used to transmit and receive information and support a communication event. Communication mechanisms are synchronous if they require both sender and receivers to be available at the same time. Otherwise, communication mechanisms are called asynchronous. - Hallway conversations are unplanned, informal exchanges of information based on opportunity. - The objective of a questionnaire is to elicit information from one or more persons in a structured manner. Clarifications of ambiguous or incomplete answers are then obtained during a structured interview. - Face-to-face meetings enable a number of participants to share, review, and negotiate issues and solutions. In order to increase the information transfer and the number of decisions made during a meeting, roles are assigned to selected participants: The facilitator is responsible for organizing the meeting and guiding its execution. The minute taker is responsible for recording the meeting. The timekeeper is responsible for keeping track of time and notifying the facilitator if a discussion consumes more time than is allocated by the agenda. - A meeting agenda consists of at least three sections: a header identifying the planned meeting location, time, and participants; a list of items participants will report on; and a list of issues to be discussed and resolved in the meeting. - A set of meeting minutes consists of three sections that correspond to the sections of the agenda. - Same time, different place groupware are tools that allow distributed users to collaborate synchronously. - Different time, different place groupware, or simply, asynchronous groupware, has had more success during the past two decades.

Software Development Model: Waterfall

- all steps of the engineering method are accomplished sequentially - The waterfall model is an activity-centered life cycle model that prescribes sequential executions of subsets of the development processes and management processes. Software development activities are performed in sequence. - All requirement activities are comleted before the system design activity starts. The goal is never to turn back once an activity is completed. The key feature of this model is the constant verification activity which ensures that each development activity does not introduce unwanted or delete mandatory requirements.

JavaScript

- an object-oriented computer programming language commonly used to create interactive effects within web browsers. - client-side script: code runs in browser after page is sent back from server often this code manipulates the page or responds to user actions -Advantages of client-side scripting: Allows for more interactivity. Can perform actions quickly without going to the server. May be easier to use for those whose browsers don't support scripts. Are available from many free resources such as Hotscripts.com and Javascript.com -Disadvantages of client-side scripting: If the user's browser is out of data, the website will not display properly. More quality assurance testing is required because different browsers support scripts differently. Not secure because anyone can look at the code in the page source. Some browsers will disable the active content and tell the user they may be harmful. - JavaScript code can be embedded in a Web page using SCRIPT tags. The output of JavaScript code is displayed as if directly entered in HTML.

SE Best Practices

- continuously refactor the design and code - use proven design patterns - acquire reusable components if possible - focus on usability - develop maintainable applications - use programming languages appropriate for application - use proven testing practices

Investigating a repo

- git diff shows your changes from last repo version - git diff <commit> shows changes in version <commit> - git log [filename] shows all commit logs - git status displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven't, and which files aren't being tracked by Git.

client constraints

- imposed by the client or the environment in which the system operates

boundary objects

- meaningful suffix for boundary objects (view, form, button, display, etc.) - What interface controls does the user need to initiate a use case? - What forms does the user need to enter data into the system? - What kind of notices/alerts/messages does the system send to the user? - Don't focus on details of user interface

control objects

- meaningful suffix for control objects (control) - coordinate between boundary and entity objects and dispatch to entity objects - one control object per use case - one control object per actor in the use case - Life span should be the extent of a use case or a user session

Version Control

- need for a logical way to organize control revisions - Any kind of practice that tracks and provides control over changes to source code. - A must in today's computing industry

entity objects

- no suffix for entity objects - Recurring nouns (Incident) - Real-word entities that need to be tracked (FieldOfficer) - Real-world activities that need to be tracked (EmergencyPlan) - Data sources or sinks (Printer)

object model

- represented in UML with class diagrams, describes the structure of the system in terms of objects, attributes, associations, and operations

dynamic model

- represented in UML with interaction diagrams, state machine diagrams, and activity diagrams, describes the internal behavior of the system

functional model

- represented in UML with use case diagrams, describes the functionality of the system from the user's point of view

activity diagram

- similar to a flow chart - represent flow of work of single object or between various objects

process framework

- the foundation for the software process - 5 activities (communication, planning, modeling, construction, and deployment)

problem statement

- the problem statement is developed by the client as a description of the problem addressed by the system - Ingredients of a problem statement: -Current situation: the problem to be solved - description of one or more scenarios - requirements (functional, nonfunctional, constraints) - project schedule - target environment - client acceptance criteria

use case diagram

- use cases are used during requirements elicitation and analysis to represent the functionality of the system. a use case describes a function provided by the system that yields a visible result for an actor - textual description: (1) unique name, (2) participating actors, (3) entry conditions, (4) exit conditions, (5) flow of events, (6) special requirements

GIT scenario

1. git clone gets you the working copy from repo 2. Make local changes in working copy 3. git commit saves your changes into version control history with a comment (commit often!) 4. git push publishes your commits to remote repository 5. git pull gets latest changes from repo to sync

client-server architecture

A network design in which client computers use a centrally administered server to share data, data storage space, and devices.

Why is software engineering needed?

Software engineering is important because specific software is needed in almost every industry, in every business, and for every function.

ls

List the contents of a directory

pwd

Print Working Directory - ie. Where are we currently

personal software process

The Personal Software Process (PSP) is a structured software development process that is intended (planned) to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code - Planning, high-level design, high-level design review, development, postmortem

Umbrella Activities

Umbrella activities are a set of steps or procedure that the software engineering team follows to maintain the progress, quality, change risks of the overall development tasks. These steps of umbrella activities will evolve through the phases of generic view of software development. Umbrella Activities are as follows: 1. Software Project Tracking and Control 2. Formal Technical Reviews 3. Software Quality Assurance 4. Software Configuration Management 5. Document Preparation and Production 6. Re-usability Management 7. Measurement and Metrics 8. Risk Management

How to define a framework activity?

What actions are appropriate for the framework activity, given: - The nature of the problem - The capabilities of the software team - The stakeholders?

How to program a modern web app?

With HTML you can create your own Website.

software process

a collection/framework of activities, actions, and tasks performed to produce high-quality software

What is a software process model?

a simplified deprecation of software process, presented from a specific perspective

associations

become attributes -relationships between classes and represent groups of links

full stack technology

browser <> web server <> storage system

Framework Activities

communication, planning, modeling, construction, deployment

cat

concatenate and print file cat original.txt

aggregation

consists-of - denote heirarchical aspects of the relationship and can have either one-to-many or many-to-many multiplicity

cp

copy file cp orignal.txt copy.txt

touch

create an empty file touch original.txt

phase patterns

define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature

stage patterns

defines a problem associated with a framework activity for the process

rm

delete file

functional requirements

describe the interactions between the system and its environment independent from implementation