Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Engineering Methodologies (Generally / What IT is? (Why projects…
Software Engineering Methodologies
Requirements engineering ( RE )
Static code analyzers
Agile
Agile values
Working software over comprehensive documentation
Customer collaboration over contract negotiation, immediate feedback from the customer/users
Responding to change over following a plan
There is of course value also on the right side but the left side is still more important
Maintain simplicity both in process and in software
Individuals and interactions over processes and tools
"If you are doing agile by the book, you are not agile"
Why?
Tackles the problem when customers want to change the plans on the fly
Waterfall is not very flexible so the agile was invented
Extreme programming (XP)
Well-known method where are requirements are expressed in user stories which are implemented as series of tasks
Relies heavily on pair programming and TDD
All tests must success when new code is integrated
Code is coded for 25 minutes then 5 min brake, this is very efficient but stressfull
Pair programming
Supports collective ownership and responsibility
Informal review because all code has been seen atleast by 2 programmers
Helps in learning by others because people are strong in different things
Immediate feedback
Problems
Can cost more because 2 programmers doing the same thing
Social problems between programmers
Sprint is 1 - 2 weeks
Scrum
Agile method similar to XP but scrum focuses more on management and not the coding
Daily (24h) scrum meetings, where people share problems and is decided when and who gives help
Scrum starts from Product Backlog which holds all the user stories
Sprints
Longer iterations than XP and scrum doesn't allow changes to the ongoing sprints
Sprint could take 2 - 4 weeks and in the end of sprint there must be some new functionality to be demonstrable
In there should be new shippable increment to the project
Sprints can't be changed but can be cancelled by the customer
Programmers start from the most important user stories and the story is given to the programmer that is able to make it the fastest
Scrum guide should be read for the exam:
https://www.scrumguides.org/
Why?
Self-organizinig teams that have a lot of responsibility on the success of project
Lean
Provides value to the customer by reducing wasteful practices
Make progress and state visible
Deliver fast and continously
Kanban
Principles
Everything shuld be visualized
Kanban board has columns ToDo, In Progress and Done that hold tasks that need to be done as post it notes
Refactoring
SC - Software change
Process of adding new functionality to existing code
Foundationof software evolution and servicing
What is?
Semantic-prevesrsing
Changing the program without modifying its observable behaviour
Easier to understand and cheaper to modify
Style smells
Use the company conventions or language syle specs
Associations between classes should be unidirectional, one way associations makes everything much simple, in UML associsations between classes only one way
Software verification and validation
Verification and validation are processes which are intended to show that a system conforms to its specs and requirements of the customer
Involves system testing and checking and review processes
Goals
Establish confidence that the software works as it should work
Static and dynamic verification
Static verification means software inspections, static analysis and formal verification
Static verification means analysis of the static system representation to discover problems
Dynamic verification is concerned with exercising and observing product behaviour using SW testing
In dynamic verification the system is executed with test data and its operational behaviour is observed
Testing
SW is the programmers baby so the tester should be someone else than the parent
Tester should be able to break the SW
TDD
Tests are written before code and passing tests give important information about project
TDD is popular in agile
Identify new functionality -> Test fails -> Implement functionality -> Test passes
Project planning and management
Project management aims
Deliver SW to customer at the agreed time
Keep costs at agreed
Deliver software that meets its requirements
Maintain spirit and performance of the team
Solve problems
Process is variable and organisation specific
Includes organization, target setting, risk analysis, selection of technologies, methods, practices, tools, also support like documentation, QA and also worktime estimation, resource availability, budget funding and success criteria
Effort estimation
Customer and team need to know amount of resource, requirements and their priority and estimate the required effort
Planning
We need to know the contribution of all members, typically 5 days a week
Reduce non-productive work like useless meetings and travelling
It is good to know that more people doing the project at the same doesn't make it twice as efficient
In some cases if there is too much people on the project it might even slow down bacause more people means more managing and communication
Some projects might even be impossible to partition
In many cases adding manpower to a late software project makes it to be even more late
Complexity of the software is often hard to estimate in advance
Productivity of individuals might vary even 10-times
Problems occur because so many unknowns, wishful thinking and people might have their agendas like sales team might want to win the job
Effort estimation
Fisma
4 more items...
COCOMO
4 more items...
Quality Assurance (QA)
Software Maintenance Processes
Software quality management
Concerned in ensuring that the product has good enough quality
Quality management provides an independent check on the software development process
The QA team should be independent from the development team
so the QA is able to take an objective view to the project
Pointing problems in someones code is problematic psychologically because someone might get hurt
Quality plans
3 more items...
SW quality
5 more items...
QM and Agile development
5 more items...
Project work
In project work, teams develop a program that run static analyzes to a Java project, output as CSV files
The program is given a Git url, fetches the code of the Java project, analyzes it and commits data in CSV file
In the project the process of creating the project is the most important! Not what comes of it!
Easy to install and works on Linux/Docker, otherwise free hands
Developing happens with SCRUM
Milestone for each sprint
Tasks should be made, they are little jobs that user stories are made off
Tools which goal is to help developers write better code without running the code
Generally
Finding and figuring out the requirements of the product
"Requirements engineering refers to the process of defining, documenting and maintaining requirements in the engineering design process"
Formal or informal interviews with stakeholders are part of most RE processes
Requirement elicitation means the process of gathering and identifying requirements for system to be developed
Problems
Stakeholders don't know what they really want
Stakeholders might not be technically inclined
Different stakeholders might have conflicting requirements
In interviews bosses might get their needs more easily through, even though it wouldn't be that important
As developer you need to speak the "language" of the customer, because customers won't speak your "language"
Requirements
Stories / Scenarios
User stories are requirements defined on very high level about something that end-user must be able to do in the ready system
Real-life examples how the system will work
As a <user role/customer>, I want to <goal to be accomplished> so that I can <reason of the goal>
Should tell what the software should do and NOT how it does it
Can be gathered from stakeholders through interviews, observing users and meetings
Can be extracted from existing documents like competing products and from current projects and also from experts, seminars and workshops
Requirement Smells is a checklist that has info on what kind of language the user stories shouldn't have, like negative statements and adjectives
Generally / What IT is?
Software egineering is concerned with the practicalities of developing and delivering useful software
Software engineering is an engineering discipline that is concerned with all aspects of software production
There is NO silver bullets!
Why / When? - Rises from the need of new software to solve some problem
After the software is ready then it needs maintaining
What is needed?
Skillfull programming
Requirements
Project management
QA - Quality assurance
Operation (Server guys)
Why projects fail?
Organizational structure, everything needs to be asked from the bosses bosses boss
Unrealistic or unarticulated goals
Software that fails to meet the real business needs
Badly defined requirements
Poor project management
Most common reasons for projects to fails
Tools for projects
Life-cycle models
Software life cycle tells how the software should be developed
Guideline to organize, plan, staff, budget, schedule and manage software project work
Process Models
Define a specific development task in terms of input/output products
Software process model represents newtworked sequence of activities, objects, transformations and events that embody strategies for accomplishing software evolution
Waterfall
Good
Provides easy to understand structure to inexperienced staff
Milestones are well understood
Sets requirement stability
Good for management control, like plansm staff and tracking
Works well when the quality is more important than cost or schedule
Easy to understand and easy to use
Bad
All requirements must be known upfront
Deliverables for each phase are locked which takes away flexibility
Can give false impression of progress
Does not reflect problem-solving nature of software development
Integration is one big risky bang at the end of project
Customer don't have much opportunities to preview the system and in some cases it might be too late
When to use
When laws order to aka software works in a critical system like military or airplane
When requirements are very well known
When product definition is stable and technology is well understood
When old product is ported to new platform or infrastructure