Software Engineering Quiz 1

Software Engineering

application of engineering principles to software development

software development profession

field of computing research that aims to improve methods and tools for software development

software engineering methodology

body of techniques used to develop software

goals of software engineering

to produce as quickly and inexpensively as possible

easy to use

satisfy user’s needs

reliable

efficient

maintainable, adaptable, enhance able, secure

aspects of software engineering

specification, design, programming, inspection and testing, static (code) and dynamic (testing) analysis “software analytics”, debugging, maintenance and evolution, version control, integration, configuration management, and deployment, code generation, test generation, analysis by AI

non technical aspects

project management, law, psychology

software complexity

problem complexity, design and implementation complexity, platform and experiment complexity, complexity due to change, dependency within code, large software systems are among the most complex artifacts ever produced by man

consequences of complexity

difficult and time consuming to maintain, cannot be fully understood by one person, doesn’t usually satisfy all user needs, residual defects, late and exceeds budget, or never finishes

methodology

broad collection of techniques and tools that addresses each phase of software development, continuously evolving, specialized for particular subfields like web and mobile applications vs real time systems vs health informatics

some influential methods

oop, agile, design patterns, test-driven design, A/B testing

Impact of LLMs

productivity and code quality, testing and reliability, maintenance and modernization, security

Software process models

graphical models of the software development process

characterize workflow between phases

have descriptive and prescriptive uses

ant model - build and fix

start coding immediately

little or no upfront analysis or design

ship initial version quickly

fix bugs and add features as required by customer

planning, architecture, documentation are minimal

drawbacks of build and fix

no stable design, code degenerates, maintenance is likely to be difficult, unpredictable schedule and scope, quality risks, works poorly for large products

phases of software development

requirements elicitation and analysis, requirements specification, design, implementation, integration, deployment, operations and maintenance, validation

requirements elicitation and analysis

determine what the software should do

requirements specification

produce a written specification of what the software should do

design

abstractly describe the structure and behavior of a software system satisfying the requirements

implementation

program the components of the system

integration

combine the components into a working system

deployment

deploy the software to end users

operations and maintenance

installation, support, repair, enhancement, adaptation, and evolution of a complete system

validation

in every phase

Waterfall

sequentially go through phases

advantages of waterfall

disciplined approach to development

careful analysis and documentation before coding can prevent costly problems

documentation produced facilitates maintenance and training

drawbacks of waterfall

difficult to convey dynamic appearance and behavior in documents

customers don’t know what they want until they see it

developers often don’t understand a specific phase until a later one

difficult to assess progress

incentive mismatch

schrage claims requirements create perverse incentives for clients to:

avoid rigorous thinking about cost, change, priorities, and risk

delegate hard design decision to IT

easy for clients to generate many requirements

devs are rewarded for building to requirements, and not for refining or removing them

schrage argues for quick prototypes based on a few requirements (20-25)

Prototyping

an incomplete executable model of an eventual system

developed rapidly based on initial requirements

provided to users for evaluation

user feedback aids refinement and validation of requirements

especially helpful with look and feel and user interactions

can also be used to validate internal design (performance or capacity)

focus is on areas of greatest riskt

to produce prototype rapidly

functionality can be omitted

non-functional constraints can be ignored (efficiency and reliability)

existing components can be reused

rapid development tools and languages can be exploited

prototype fidelity

traditional prototypes have high fidelity to final product

executable is fairly detailed

interactive mockups of UI

prototypes can also vary in fidelity (storyboards, drawings)

protype validation

prototype is provided to end users

use it as they see fit or run specified tests

may involve user interviews, focus groups, or surveys

throwaway prototyping

prototypes are not build upon (poorly understood parts first, dev time is important)

evolutionary prototyping

prototype is iteratively refined and extended to obtain final system (need to refactor) (do well understood parts first, modify easily)

operational prototyping

combines throwaway and evolutionary to achieve stable and rapid results

evolutionary prototype is constructed and made into a baseline using conventional methods

only well understood requirements are implemented

then copies of baseline are sent to multiple customer sites with prototyper and log problems and feature request

after, prototyper constructs throwaway prototype on top of base line

if new changes aren’t effected, they are removed, if they are liked, the dev team actually adds them

based on all CRs, a new evolutionary prototype is made

risks of prototyping

possible neglect of upfront analysis

users may mistake prototype for a nearly finished product

neglect of non-visible features

accommodating users may lead to feature creep

excessive effort

contractual difficulties

A/B testing

experimental comparison of 2 versions of webpage, app feature, or interface to determine which is better

objective overall evaluation criterion (OEC) is specified - conversion rate, signup rate, units purchased, revenue, profit

versions are assigned at random to different end users persistently

users interactions with site are monitored

uses techniques for design and analysis or experiments to detect statistically significant differences in OEC values between versions

opportunistic programming

programmers prototype, ideate, and discover

emphasizes speed and ease of development over maintainability and robustness

programming for own use

involves web foraging and just in time learning for ideas and examples

built from scratch using high level tools

copy and paste

iterate rapidly

code is considered impermanent

unique debugging challenges

AI in opportunistic programming

suggest solutions and features

generate code snippets

create variations of a feature to test different ideas

generate documentation

assist debugging

disadvantages of opportunistic programming

right to intellectual property

plagiarism

can create a foundation of code that hard to modify and debug

reliability

security

incremental delivery

system is developed and delivered in a series if increments or builds

each increment provides a subset of system functionality

services are allocated to increments based on customer priorities

early feedback on early increments

high risk features are delivered early only if needed by customer

conventional development process is applied to each increment

advantages of incremental delivery

client can exploit product functionality sooner

developer gets early feedback compared to waterfall

requires planning for future enhancements

highest priority services get most testing

stakeholders see tangible progress every iteration

small increments speed root-cause analysis and fixes

early increments reveal scalability and operability needs sooner

clear, short term goals and frequent successes keep morale high

risks of incremental delivery

it may be difficult to integrate later build with earlier ones

overhead of many releases

frequent UI/behavior changes increase training and support load

can degrade to build and fix

Spiral model

assumes that risk management is a paramount issue