Software Development Life cycle and processes

1
Software Development Life cycle and processes

• Presented by
• Nagy Ágnes
• Varga Dóra

Móré Szilvia, Zarnóczki Fanni
2
Overview

• The Systems Development Life Cycle (SDLC), or
  Software Development Life Cycle in systems
  engineering is the process of creating or
  altering systems. The models and methodologies
  that people use to develop these systems. The
  concept generally refers to computer or
  information systems.
• Systems Development Life Cycle is any logical
  process used by a systems analyst to develop an
  information system .
• Including
• requirements
• validation,
• training,
• user ownership
• To manage the level of complexity, a number of
  system development life cycle (SDLC) models have
  been created.
• For example Waterfall focus on complete and
  correct planning to guide large projects and
  risks to successful and predictable results.

3
Systems development phases

• It has 6 steps
• Initiation/planning
• Requirements gathering and analysis
• Design
• Build or cording
• Testing
• Operations and maintenance

4
Software lifecycle model

• A software life cycle model depicts the
  significant phases or activities of a software
  project from conception until the product is
  retired. It specifies the relationships between
  project phases, including transition criteria,
  feedback mechanisms, milestones, baselines,
  reviews, and deliverables. Typically, a life
  cycle model addresses the  phases of a software
  project requirements phase, design phase,
  implementation, integration, testing, operations
  and maintenance. Much of the motivation behind
  utilizing a life cycle model is to provide
  structure to avoid the problems of the
  "undisciplined hacker" or corporate IT bureaucrat
  (which is probably ten times dangerous then
  undisciplined hacker).  As always, it's a matter
  of picking the right tool for the job, rather
  than picking up your hammer and treating
  everything as a nail.

5
Initiation/planning

• To generate a high-level view of the intended
  project and determine the goals of the project.
• Projects are typically evaluated in three areas
  of feasibility economical, operational, and
  technical
• It is also used as a reference to keep the
  project on track

6
Requirements gathering and analysis

• The goal of systems analysis is to determine
  where the problem is in an attempt to fix the
  system.
• This step involves breaking down the system in
  different pieces and drawing diagrams to analyze
  the situation.

7
Design

• Systems design includes screen layouts,
  business rules, process diagrams and other
  documentation.
• Design elements describe the desired software
  features in detail, and generally include
  functional hierarchy diagrams, screen layout
  diagrams, tables of business rules, business
  process diagrams, pseudocode, and a complete
  entity-relationship diagram with a full data
  dictionary.

8
Build or cording

• Modular and subsystem programming code is
  accomplished in this stage
• Unit testing and module testing are done in this
  stage by the developers

9
Testing

• The code is tested at various levels in software
  testing.
• Types of testing
• Unit testing
• System testing
• Integration testing
• Black box testing
• White box testing
• Regression testing
• Automation testing
• User acceptance testing
• Performance testing

10
Operations and maintenance

• Maintaining the system is an important aspect of
  SDLC.
• New changes will be implemented, which will
  require system updates.

11
Systems development life cycle models

• Waterfall Model
• Incremental Model
• Spiral Model
• Prototyping Model

12
Waterfall Model

• most common and classic of life cycle models
• linear-sequential life cycle model
• very simple to understand and use 
• each phase must be completed before the next
  phase can begin

13
Incremental Model

• The incremental model is an intuitive approach to
  the waterfall model.
• Multiple development cycles take place here,
  making the life cycle a multi-waterfall cycle.
  
• Cycles divided up into smaller, more easily
  managed iterations, that passes through the
  requirements, design, implementation and testing
  phases.
• A working version of software is produced during
  the first iteration

14
Spiral Model
                                                 
                       

• similar to the incremental model, with more
  emphases placed on risk analysis
• The spiral model has four phases Planning, Risk
  Analysis, Engineering and Evaluation
• A software project repeatedly passes through
  these phases in iterations (called Spirals in
  this model). 
• Requirements are gathered during the planning
  phase. 
• Software is produced in the engineering phase,
  along with testing at the end of the phase. 

15
Prototyping Model

• The goal of prototyping counter the first two
  limitations of the waterfall model discussed
  earlier.
• The basic idea instead of freezing the
  requirements before a design or coding can
  proceed, a throwaway prototype is built to
  understand the requirements.
• Development of the prototype obviously undergoes
  design, coding and testing.

16
ConclusionStrengths
Weaknesses

• Control
• Monitor Large Projects
• Detailed step
• Evaluate costs and completion targets
• Documentation
• Well defined user input
• Ease of maintenance
• Development and design standards
• Tolerates changes in MIS staffing

• Increased development time
• Increased development cost
• Systems must be defined up front
• Rigidity
• Hard to estimate costs, project overruns
• User input is sometimes limited

17
Structure of testing and development
18
Software release and lifecylce

• A software release is the distribution (whether
  public or private) of an initial or upgraded
  version of a computer software product. The
  software engineers and company doing the work
  decide on how to distribute the program or
  system, or changes to that pre downloads and
  compact discs.
• The software release lifecycle is composed of
  different stages that describe the stability of a
  piece of software and the amount as the
  development process proceeds.

19
Pre-Alpha

• In contrast to alpha and beta versions, the
  pre-alpha is not feature complete. When it is
  used, it refers to all activities performed
  during the software project prior to software
  testing. These activities can include
  requirements analysis, software design, software
  development and unit testing.
• In typical open source development, there are
  several types of pre-alpha versions. Milestone
  versions include specific sets of functions and
  are released as soon as the functionality is
  complete. Nightly builds are versions that are
  usually automatically checked out from the
  revision control system and built, typically
  overnight these versions allow the testers to
  test the recently implemented functionality
  immediately, and find the new bugs.

20
Alpha

• The alpha build of the software is the build to
  the internal software testers, that is, people
  different from the software engineers, sometimes
  to the public, but usually internal to the
  organization or community that develops the
  software. In a rush to market, more and more
  companies are engaging external customers or
  value-chain partners in their alpha testing
  phase. This allows more extensive usability
  testing during the alpha phase.
• In the first phase of testing, developers
  generally test the software using white box
  techniques. Additional validation is then
  performed using black box or gray box techniques,
  by another dedicated testing team, sometimes
  concurrently. Moving to black box testing inside
  the organization is known as alpha release

21
Beta

• "Beta" is a nickname for software which has
  passed the alpha testing stage of development and
  has been released to users for software testing
  before its official release. It is the prototype
  of the software that is released to the public.
  Beta testing allows the software to undergo
  usability testing with users who provide
  feedback, so that any malfunctions these users
  find in the software can be reported to the
  developers and fixed. Beta software can be
  unstable and could cause crashes or data loss.
• A "beta version" is the first version released
  outside the organization or community that
  develops the software, for the purpose of
  evaluation or real-world black/grey-box testing.
  The process of delivering a beta version to the
  users is called beta release. Beta level software
  generally includes all features, but may also
  include known issues and bugs of a less serious
  variety.

22
Release candidate

• The term release candidate (RC) refers to a
  version with potential to be a final product,
  ready to release unless fatal bugs emerge. In
  this stage of product stabilization (read QA
  cycle), all product features have been designed,
  coded and tested through one or more Beta cycles
  with no known showstopper-class bug.
• A release is called code complete when the
  development team agrees that no entirely new
  source code will be added to this release. There
  may still be source code changes to fix defects.
  There may still be changes to documentation and
  data files, and to the code for test cases or
  utilities. New code may be added in a future
  release.

23
RTM

• The term "release to manufacturing" or "release
  to marketing" (both abbreviated RTM)also known
  as "going gold"is used to indicate that the
  software has met a defined quality level and is
  ready for mass distribution either by electronic
  means or by physical media. RTM usually does not
  mean the software is actually released it would
  in most cases mean that the software is being
  released to manufacturers, for pre-installation
  on ready machines, or for the manufacturer to
  adjust the software for their manufactured
  hardware and settings.
• RTM happens prior to general availability (GA)
  when the product is released to the public

24
General availability (GA)

• General availability (GA) is the point where all
  necessary commercialization activities have been
  completed and the software has been made
  available to the general market either via the
  web or physical media.
• Commercialization activities could include but
  are not limited to the availability of media
  world wide via dispersed distribution centers,
  marketing collateral is completed and available
  in as many languages as deemed necessary for the
  target market, etc. The time between RTM and GA
  can be from a week to months in some cases before
  a generally available release can be declared
  because of the time needed to complete all
  commercialization activities required by GA.
• Another term with a meaning almost identical to
  GA is FCS, for First Customer Shipment. Some
  companies (such as Sun Microsystems and Cisco)
  use FCS to describe a software version that has
  been shipped for revenue.

25

• Boxed copy
• A boxed copy is a physical version of the final
  product, printed on a disc that is complete with
  disc graphic art. This term is used mostly by
  reviewers to differentiate from other forms of
  the released product (e.g., a downloaded copy, or
  a gold master burned on a generic disc). A boxed
  copy does not necessarily come enclosed in a box
  it refers to the disc itself. In other words, we
  can say we get something tangible.
• Web release
• A web release is a means of software delivery
  that utilizes the Internet for distribution. No
  physical media are produced in this type of
  release mechanism by the manufacturer. This is
  sometimes also referred to as Release To Web
  (RTW).

26
End-of-life (EOL)

• Sometimes software companies stop selling or
  supporting their software products (e.g., not
  releasing new patches). At this point the product
  will be said to be in the status of "legacy",
  "vintage" or "end of life."

27
ISO 12207

• Farkas Karolina, Sidó Dávid, Vass Lili

28

• iSO 12207 is an ISO standard for software
  lifecycle processes. It aims to be 'the' standard
  that defines all the tasks required for
  developing and maintaining software
• The ISO 12207 standard establishes a process of
  lifecycle for software, including processes and
  activities applied during the acquisition and
  configuration of the services of the system. Each
  Process has a set of outcomes associated with it.
  There are 23 Processes, 95 Activities, 325 Tasks
  and 224 Outcomes.

29

• The standard has the main objective of supplying
  a common structure so that the buyers, suppliers,
  developers, maintainers, operators, managers and
  technicians involved with the software
  development use a common language. This common
  language is established in the form of well
  defined processes. The structure of the standard
  was intended to be conceived in a flexible,
  modular way so as to be adaptable to the
  necessities of whoever uses it. The standard is
  based on two basic principles modularity and
  responsibility.

30

• Modularity means processes with minimum
  couplingand maximum cohesion. Responsibility
  means to establish a responsibility for each
  process, facilitating the application of the
  standard in projects where many people can be
  legally involved.
• The set of processes, activities and tasks can be
  adapted according to the software project. These
  processes are classified in three types basic,
  for support and organizational. The support and
  organizational processes must exist independently
  of the organization and the project being
  executed. The basic processes are instantiated
  according to the situation.

31
Primary lifecycle processes

• The primary lifecycle processes contain the core
  processes involved in creating a software
  product. These processes are divided into five
  different main processes
• Acquisition
• Supply
• Development
• Operation
• Maintenance

32
Activities

• Each phase within the primary lifecycle processes
  can be divided into different activities. This
  chapter explains the different activities for
  each primary lifecycle process.

33
Acquisition

• Initiation during this activity the following
  tasks are completed
• The need is described why to acquire, develop, or
  enhance a product
• Sytem requirements are defined and approved if
  applicable
• The global software requirements are defined
• Evaluation of other options, like a purchase of
  an off-the-shelf product or enhancement of an
  existing product
• If an off-the-shelf product is purchased, the
  software requirements of this product need to be
  analyzed.
• An acquisition plan is developed, this plan will
  be used further on during the acquisition phase
• Acceptance criteria are defined

34

• Request for proposal preparation during this
  activity the following tasks are completed
• Acquisition requirements, like System
  requirementsand technical constraints such as
  target environment, are defined.
• Required ISO/IEC 12207 process for the project
  are defined and changed accordingly if needed.
• Contract milestones for reviewing and supplier's
  progress audits are defined.

35

• Prepare Contract during this activity the
  following tasks are completed
• Selection procedure for suppliers are developed
• Suppliers, based on the developed selection
  procedure, are selected
• The tailor-made ISO/IEC 12207 standard must be
  included in the contract
• Negotiate changes during this activity the
  following tasks are completed
• Negotiations are held with the selected
  suppliers

36

• Update contract during this activity the
  following tasks are completed
• Contract is updated with the result from the
  negotiations in the previous activity.
• Supplier monitoring during this activity the
  following tasks are completed
• Activities of the suppliers according to the
  agreements made are monitored
• Work together with suppliers to guarantee timely
  delivery if needed.

37

• Acceptance and completion during this activity
  the following tasks are completed
• Accaptance test and procedures are developed
• Acceptance and testing on the product is
  conducted
• Configuration management on the delivered product
  is conducted

38
Supply

• During the supply phase a project management
  plan is developed. This plan contains information
  about the project such as different milestones
  that need to be reached. This project management
  play is needed during the next phase which is the
  development phase.

39
Development

• During the development phase the software product
  is designed, created and tested and will result
  in a software product ready to be sold to the
  customer. Throughout time many people have
  developed means of developing a software
  application. The choice of developing method
  often depends on the present situation. The
  development method which is used in many projects
  is the V-model. Techniques that can be used
  during the development are UML for designing and
  TMsp for testing. This entry contains the most
  important steps of the V-model.

40

• Define software requirements during this
  activity the following tasks are completed
• Gather the software requiremnets, or demands, for
  the product that is to be created.
• Create High level design during this activity
  the following tasks are completed
• A basic layout of the product is created. This
  means the setup of different modules and how they
  communicate with each other. This design does not
  contain very much detail about the modules.
• Create Module design
• The different modules present in the High level
  design are designed separately. The modules are
  designed in as much detail as possible.

41

• Coding
• The code is created according to the high level
  design and the module design.
• Execute Module test
• The different modules are tested for correct
  functioning. If this is the case the project can
  move to the next activity, else the project
  returns to the module design phase to correct any
  errors.
• Execute Integration test
• The communication between modules is tested for
  correct functioning. If this is the case the
  project can move to the next activity, else the
  project falls back to the high level design to
  correct any errors.

42

• Execute Sytem test
• This test checks whether all software
  requirements are present in the product. If this
  is the case the product is completed and the
  product is ready to be transferred to the
  customer. Else the project falls back to the
  software requirements activity and the software
  requirements have to be adjusted.

43
Operation

• The operation and maintenance phases occur
  simultaneously, the operation-phase consists of
  activities like assisting users in working with
  the created software product.

44
Maintenance

• The maintenance-phase consists of
  maintenance-tasks to keep the product up and
  running. The maintenance includes any general
  enhancements, changes and additions, which might
  be required by the end-users.These defects and
  deficiencies are usually documented by the
  developing organisation to enable future
  solutions and known issues addressing in any
  future maintenance releases.

45

• Thank you for your attention!
• Any question?

46
INFORMATION QUALITY

• Prepared by Miliosz Katalin and Gerbár Eszter

47

• Information quality (IQ) is a term to describe
  the quality of the content of information systems.

48
Conceptual problems

• Information quality data quality
• Most information system practitioners use the
  term synonymously with data quality
• However as many academics make a distinction
  between data and information, some will insist on
  a distinction between data quality and
  information quality

49
Dimensions and metrics of Information Quality

• Information quality is a measure of the value
  which the information provides to the user of
  that information
• Quality is often perceived as subjective and
  the quality of information can vary among users
  and among uses of the information.
• Accuracy can be seen as just one element of IQ,
  can also be seen as encompassing many other
  dimensions of quality.

50
Dimensions or elements used in assessing
subjective Information Quality

• Intrinsic IQ Accuracy, Objectivity,
  Believability,Reputation
• Contextual IQ Relevancy, Value-Added,
  Timeliness, Completeness, Amount of information
• Representational IQ Interpretability, Ease of
  understanding, Concise representation, Consistent
  representation
• Accessibility IQ Accessibility, Access security

51

• Authority Authority refers to the expertise or
  recognized official status of a source. Consider
  the reputation of the author and publisher.
• Scope of coverage Scope of coverage refers to
  the extent to which a source explores a topic.
  Consider time periods, geography or jurisdiction
  and coverage of related or narrower topics.

52

• Composition and Organization Composition and
  Organization has to do with the ability of the
  information source to present its particular
  message in a coherent, logically sequential
  manner.
• Objectivity Objectivity is the bias or opinion
  expressed when a writer interprets or analyze
  facts. Consider the use of persuasive language

53

• Integrity adherence to moral and ethical
  principles
• Comprehensiveness
• Validity Validity of some information has to do
  with the degree of obvious truthfulness which the
  information caries

54

• Uniqueness uniqueness of a given piece of
  information is intuitive in meaning, it also
  implies not only the originating point of the
  information but also the manner in which it is
  presented.
• Timeliness Timeliness refers to information that
  is current at the time of publication. Consider
  publication, creation and revision dates
• Reproducibility (utilized primarily when
  referring to instructive information)Means that
  documented methods are capable of being used on
  the same data set to achieve a consistent result.

55

• Thank you for your attention!