soft eng

• Characteristics of Software Product

  • Maintainability
  • Dependability and Security
  • Efficiency
  • Acceptability
• Software


  • Set of programs
  • Computer instructions or programs
  • Provide desired features, function, and performance
  • Data structures that manipulate information (Array, Matrix, Trees, Queue)
  • Documentation that describes the operation and use of programs
  • Solve problem and tasks
  • Developed or engineered
  • Does not "wear out"
  • Custom-built
  • Example: MS Word (a word processor)
• Program


  • Set of instructions
• Application


  • Implementation of software
• Software is a product

  • Delivers computing potential
  • Produces, manages, acquires, modifies, displays, or transmits information
  • Acts as a vehicle for delivering a product
  • Supports or directly provides system functionality
  • Controls other programs (e.g., an operating system)
  • Affects communications (e.g., networking software)
  • Helps build other software (e.g., software tools)
• List of Software Applications


  • System Software: Manages hardware and provides essential services (e.g., operating systems)
  • Application Software: User-focused programs for specific tasks (e.g., word processors, browsers)
  • Engineering/Scientific Software: Tailored for scientific or engineering purposes (e.g., simulations, CAD)
  • Embedded Software: Runs dedicated hardware in devices like smartphones or washing machines
  • Product-Line Software: Offers consistent features across related product lines
  • Web Applications (WebApps): Accessed through browsers, providing online services
  • AI Software: Uses artificial intelligence for tasks like image recognition or language processing
• Software Development Concepts


  • Ubiquitous computing—wireless networks
  • Netsourcing—the web as a computing engine
  • Open source—"free" source code open to the computing community
  • Data mining
  • Grid computing
  • Cognitive machines
  • Software for nanotechnologies
• Legacy Software Must Be

  • Adapted
  • Enhanced
  • Extended
  • Re-architected
• • Some realities: Understand the problem before a software solution is developed
  • Design becomes a pivotal activity
  • Software should exhibit high quality
  • Software should be maintainable
• Software Engineering


  • An engineering discipline concerned with all aspects of software production
  • Establishment and use of sound engineering principles to obtain economical and reliable software working efficiently on real machines
• • According to IEEE: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; The application of engineering to software
  • 60% development costs, 40% testing costs
• The Software Process


  1. Collection of activities, actions, and tasks

  2. Activity: Achieve a broad objective (e.g., communication with stakeholders)

  3. Action: Set of tasks (e.g., an architectural design model)

  4. Task: Well-defined objective producing a tangible outcome (e.g., conducting a unit test)
• Process Framework


  1. Foundation for a complete software engineering process

  2. Communication: Understand stakeholders' objectives for the project

  3. Planning: Software project plan defines the software engineering work by describing the technical tasks to be conducted

  4. Modeling: Create a "sketch" of the thing to understand the big picture architecturally

  5. Construction: Combines code generation (manual or automated) and testing

  6. Deployment: Deliver the software to the customer
• Software Increment


  1. Each project iteration produces a software increment

  2. As each increment is produced, the software becomes more and more complete
• Umbrella Activities


  Software project tracking and control
• Deployment


  The software is delivered to the customer
• Software Increment


  Each project iteration produces a software increment
• As each increment is produced, the software becomes more and more complete
• Umbrella Activities


  • Software project tracking and control
  • Risk management
  • Software quality assurance
  • Technical reviews
  • Measurement
  • Software configuration management
  • Reusability management
  • Work product preparation and production
• George Polya (Hungarian Mathematician): '1. Understand the problem (communication and analysis)<|>2. Plan a solution (modeling and software design)<|>3. Carry out the plan (code generation)<|>4. Examine the result for accuracy (testing and quality assurance)'
• Hooker’s General Principles


  • The Reason It All Exists – to provide value to its users
  • Keep It Simple – all design should be as simple as possible, but no simpler
  • Maintain the Vision – a clear vision is essential to the success of a software project
  • What You Produce, Others Will Consume - always specify, design, and implement knowing someone else will have to understand what you are doing
  • Be Open to the Future - never design yourself into a corner
  • Plan Ahead for Reuse - Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated
  • Think! - Placing clear, complete thought before action almost always produces better results
• Software Process


  A framework for the activities, actions, and tasks that are required to build high-quality software
• Generic Process Framework [CPMCD]

  • Project tracking and control
  • Risk management
  • Quality assurance
  • Configuration management
  • Technical reviews
• Process Flow


  • Describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time
  • The hierarchy of technical work within the software process is activities, encompassing actions, populated by tasks
  • Linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment
  • Iterative process flow repeats one or more of the activities before proceeding to the next
  • Evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software
  • Parallel process flow executes one or more activities in parallel with other activities
• Task Set


  • A list of the task to be accomplished
  • A list of the work products to be produced
• The team chooses a task set that best accommodates the needs of the project
• This implies that a software engineering action can be adapted to the specific needs of the software project and the characteristics of the project team
• Task Set


  The team chooses a task set that best accommodates the needs of the project. This implies that a software engineering action can be adapted to the specific needs of the software project and the characteristics of the project team
• Process Patterns


  Describes a process-related problem encountered during software engineering work, identifies the environment in which the problem has been encountered, and suggests one or more proven solutions to the problem. A process pattern provides a template—a consistent method for describing problem solutions within the context of the software process
• Pattern Name


  Meaningful name describing the pattern within the context of the software process
• Forces


  The environment in which the pattern is encountered and the issues that make the problem visible and may affect its solution
• Initial Context


  Describes the conditions under which the pattern applies
• Resulting Context


  Describes the conditions that will result once the pattern has been successfully implemented
• Related Patterns


  Provide a list of all process patterns that are directly related to this one
• Known Uses and Examples

  Indicate the specific instances in which the pattern is applicable
• Prescriptive Models


  Prescriptive process models were originally proposed to bring order to the chaos of software development
• Waterfall Model


  Sometimes called the classic life cycle, suggests a systematic, sequential approach to software development
• Advantages of Waterfall Model


  • Simple and easy to understand
  • Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process
  • Works well for smaller projects where requirements are clearly defined and very well understood
  • Phases are processed and completed one at a time. Phases do not overlap
• Disadvantages of Waterfall Model

  • Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage
  • No working software is produced until late during the life cycle
  • High amounts of risk and uncertainty
  • Not a good model for complex and object-oriented projects
  • Poor model for long and ongoing projects
  • Not suitable for the projects where requirements are at a moderate to high risk of changing
• V Model (Verification and Validation)


  An extension of the waterfall model and is based on the association of a testing phase. For every single phase in the development cycle, there is a high-disciplined model, and the next phase starts only after completion of the previous phase. Once code has been generated, the team moves up the right side of the V, essentially performing a series of tests (quality assurance actions) that validate each of the models created as the team moved down the left side. The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work